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About this document 


When to use this document 


This document describes the Simplified Message Desk Interface (SMDI) 
feature package (NTX732AA) and its associated features. SMDI integrates the 
following three features: call forwarding, message waiting, and uniform call 
distribution. SMDI allows the user to forward incoming calls to a message 
desk, retrieve messages from a message desk, and optionally block restricted 
directory numbers from being presented to the SMDI. This document is 
intended for the use of SMDI support personnel. 


How to check the version and issue of this document 


The version and issue of the document are indicated by numbers, for example, 
01.01. 


The first two digits indicate the version. The version number increases each 
time the document is updated to support a new software release. For example, 
the first release of a document is 01.01. In the next software release cycle, the 
first release of the same document is 02.01. 


The second two digits indicate the issue. The issue number increases each time 
the document is revised but re-released in the same software release cycle. For 
example, the second release of a document in the same software release cycle 
is 01.02. 


To determine which version of this document applies to the software in your 
office and how documentation for your product is organized, check the release 
information in Product Documentation Directory, 297-8991-001. 


This document is written for all DMS-100 Family offices. More than one 
version of this document may exist. To determine whether you have the latest 
version of this document and how documentation for your product is 
organized, check the release information in Product Documentation Directory, 
297-899 1-001. 


DMS-100 Family MDC SMDI Setup and Operation SN04 and up 


Xiv 


References in this document 
The following documents are referred to in this document: 


Commands Reference Manual, 297-1001-822 
Customer Data Schema Reference Manual, 297-Y Y Y Y-351 
Log Report Reference Manual, 297-Y Y Y Y-840 


Meridian Digital Centrex Station Message Detailed Recording Reference 
Manual, 297-2071-015 


Office Parameters Reference Manual, 297-Y YY Y-855 
Operational Measurements Reference Manual, 297-Y Y Y Y-814 
Service Order Reference Manual, 297-Y Y Y Y-808 

Translations Guide, 297-Y YY Y-350 


What precautionary messages mean 


The types of precautionary messages used in Nortel Networks documents 
include attention boxes and danger, warning, and caution messages. 


An attention box identifies information that is necessary for the proper 
performance of a procedure or task or the correct interpretation of information 
or data. Danger, warning, and caution messages indicate possible risks. 


Examples of the precautionary messages follow. 


ATTENTION 


Information needed to perform a task 


ATTENTION 
If the unused DS-3 ports are not de-provisioned before a DS-1/VT 
Mapper is installed, the DS-1 traffic will not be carried through the 
DS-1/VT Mapper, even though the DS-1/VT Mapper is properly 
provisioned. 
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DANGER 
Possibility of personal injury 


DANGER 

Risk of electrocution 

Do not open the front panel of the inverter unless fuses F1, 
F2, and F3 have been removed. The inverter contains 
high-voltage lines. Until the fuses are removed, the 
high-voltage lines are active, and you risk being 
electrocuted. 


WARNING 
Possibility of equipment damage 


DANGER 

Damage to the backplane connector pins 

Align the card before seating it, to avoid bending the 
backplane connector pins. Use light thumb pressure to 
align the card with the connectors. Next, use the levers on 
the card to seat the card into the connectors. 


CAUTION 


Possibility of service interruption or degradation 


CAUTION 

Possible loss of service 

Before continuing, confirm that you are removing the card 
from the inactive unit of the peripheral module. Subscriber 
service will be lost if you remove a card from the active 
unit. 


How commands, parameters, and responses are represented 
Commands, parameters, and responses in this document conform to the 
following conventions. 
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Input prompt (>) 
An input prompt (>) indicates that the information that follows is a command: 


>BSY 


Commands and fixed parameters 
Commands and fixed parameters that are entered at a MAP terminal are shown 
in uppercase letters: 


>BSY CTRL 


Variables 
Variables are shown in lowercase letters: 


>BSY CTRL ctrl_no 


The letters or numbers that the variable represents must be entered. Each 
variable is explained in a list that follows the command string. 


Responses 
Responses correspond to the MAP display and are shown in a different type: 


FP 3 Busy CTRL 0: Command request has been submitted. 
FP 3 Busy CTRL 0: Command passed. 


The following excerpt from a procedure shows the command syntax used in 
this document: 


1 Manually busy the CTRL on the inactive plane by typing 
>BSY CTRL ctrl_no 
and pressing the Enter key. 
where 


ctrl_no 
is the number of the CTRL (0 or 1) 


Example of a MAP response 


FP 3 Busy CTRL 0: Command request has been submitted. 
FP 3 Busy CTRL 0: Command passed. 
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1 Learning the basics of SMDI 


What type of message desk works with SMDI? 


Simplified Message Desk Interface (SMDI) is implemented as described in 
Bell Communications Research Technical Reference, Interface 
Description-Interface Between Customer Premise Equipment; Simplified 
Message Desk and Switching System: [AESS, TR-TS Y-000283. All message 
desk systems that support the message protocol standards are also defined in 
TR-TSY-000283 and are compatible with the DMS-100, 

Communications Server 2000 (CS 2000), and CS 2000 - Compact switches 
Unless specifically indicated, any features or interactions that work on a 
DMS-100 switch also work on CS 2000 and CS 2000 - Compact switches. 


SMDI functions 


The Call Forwarding features enable a user to forward calls to another 
directory number (DN) when he or she is not available to answer calls. 


The Message Waiting (MWT) feature enables a caller to set up a please call 
me request. The please call me request is passed on to the user by a message 
waiting lamp or by stuttered dial tone. This feature is only available for calls 
within a customer group. 


In many companies, a message desk service is provided to give users a central 
directory number to which their calls can be forwarded when they are not 
available to answer the phone. By using the uniform call distribution (UCD) 
capability, one or more message desk directory numbers can be supported, 
with calls being distributed automatically to message desk lines. 


SMDI integrates call forwarding, message waiting, and UCD with a datalink 
interface to a message desk system as shown in the following figure. 
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Figure 1-1 SMDI overview 
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What is a message desk? 


A message desk is a central answering service which takes calls for users not 
available to answer their phones. Users access this service by call forwarding 
their phones to the message desk DN. 


What is the message desk system? 


The message desk system provides capabilities for answering the calls that 
users call forward to a message desk directory number. 


A message desk can be either a voice messaging system (VMS) or a text 
messaging system (TMS). Both systems use a datalink connection to a 
telephone switch to receive incoming call information and to issue two types 
of notification: 


e message waiting notification - sent when messages have been recorded 

e cancel message waiting notification - sent when messages have been 
retrieved 

A voice messaging system 1s an automated recording device which can do the 

following: 

e answer calls and play an appropriate recorded announcement to the caller 

e record a message from the caller 

e retrieve and play that message to the appropriate user 

A text messaging system uses a visual display unit with a keyboard to provide 

a message desk agent with the following: 

e an information display for each incoming call 

e atext entry facility to record messages 

e atext retrieval facility to display all the messages for a user 


The operations of the voice messaging system and the text messaging system 
are described in the following sections. 


What is the DNSUPPR feature? 


The Directory Number Suppression (DNSUPPR) feature prevents the 
directory numbers of restricted calling stations and forwarding-from stations, 
from being presented to a SMDI. 


The operation of the DNSUPPR feature is described in the following sections. 


How the text messaging system works 


The TMS electronically automates the recording, filing, and retrieval of 
messages. The TMS communicates with each message desk agent using a 
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terminal and a keyboard. Figure 1-2, "Text messaging system," shows the 
configuration of a TMS. The device controller card linking the datalink and the 
DMS-100 switch is a 1X67 card, 1X89 card, or a FX30 card. The card shown 
in the figure is a 1X67 card. Each SMDI device must have the assignment of 
one card. The ports of the assigned cards can not have another purpose. The 
CS 2000 - Compact does not use a device controller card. A TCP/IP datalink 
is set up between the CS LAN and the TMS. 


Note: If the 1X67BC or 1X67BD circuit packs are being used, all SMDI 
links should be set to port 0. 


Figure 1-2 Text messaging system 
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All calls forwarded to the message desk are answered by agents. The switch 
sends the call information to the TMS over the datalink. The call details are 


e user's DN 
e caller's DN (if available) 
e call type (call forward busy, call forward no answer, call forward all) 


e message desk number and line termination number of the line of the UCD 
group that the call is on 


The TMS displays the pertinent call details on the message desk attendant's 
terminal. If the user has supplied additional information, such as whereabouts 
or schedule, this is also displayed. 


Note: The user supplies the additional information by calling the message 
desk DN or by direct input on a TMS terminal. 


The caller can leave a message for the user. The message desk agent enters the 
message through the terminal keyboard. The TMS then signals the switch to 
activate a message waiting indicator (MWI) for the user. 


Retrieving messages from the text message system 
A user who has messages waiting at the SMDI message desk is notified by an 
active message waiting indicator. The user retrieves messages from the 
message desk either by calling the message desk or by using a TMS terminal. 
The user calls the message desk by dialing one of the following: 


e the message desk UCD DN 
e the Call Request Retrieval (CRR) feature access code (if the station has 
CRR assigned) 


The CRR method of retrieval is recommended to maximize the effectiveness 
of the SMDI capability. 
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The procedures for calling the message desk and for using a TMS terminal are 


described in the following table. 


Table 1-1 Calling the message desk 


Action 


The user dials the message desk UCD 
DN or uses the call request retrieval 
code. 


The agent answers the call. 


The agent delivers the messages to the 
user. 


Table 1-2 Using a TMS terminal 


System response 


The switch 


e notifies the TMS of the incoming 
call by transmitting a call detail 
message (showing the call type as 
message-retrieval or direct) over 
the datalink 


* connects the call to a message 
desk agent 


The agent's terminal displays the 
messages for the user. 


The TMS notifies the switch through the 
datalink to deactivate the user's 
message waiting indicator 


Action 


System response 


The user enters the DN and any other 
information required by TMS ona TMS 
terminal. 


How the voice messaging system works 


Messages are displayed for the user, 
and the TMS notifies the Voice switch 
through the datalink to deactivate the 
message waiting indicator. 


The VMS automatically stores and plays back the calling party voice message. 
The message transmits as delivered, without requiring an agent. Figure 1-3, 
"VMS for DMS-100 configuration," shows the configuration of a voice 
messaging system. The device controller card linking the datalink and the 
DMS-100 switch can have a 1X67 card, a 1X89 card, or a FX30 card. Shown 
in the figure is 1X67. Each SMDI device requires one card. The remaining 
ports of the assigned cards can not be used. Figure 1-4, "VMS for 

CS 2000 - Compact configuration,” shows the configuration for a 

CS 2000 - Compact office. A CS 2000 - Compact uses a TCP/IP connection 
between the CS LAN and the VMS system. 


Note: If the 1X67BC or 1X67BD circuit packs are being used, all SMDI 


links should be set to port 0. 
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Figure 1-3 VMS for DMS-100 configuration 
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Figure 1-4 VMS for CS 2000 - Compact configuration 


imc em Oe es ese Ps Sg oe eS a ews q 
L | P i 
| Loca Customer Premises | CS 2000 - Compact 
Y 
| ~~] Line Media | 


. Customer Galeway ee ee 

e Stations | C 
| S 

GIN 

73E N IP data link* | 


CS 2000 
Core 
Manager 
or CBM 


2 
| Remote Node 
l 
| ; 
l ZEE | \ 
l e Customer 
| e Stations | 
* If the customer has a VMS that 
| Fase |S l only supports RS-232, an RS-232 
| \ | to IP converter is required at the 
l l local customer premises. 
| AEN Re E E A E E E, J 
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the IP datalink stops between the VMS and the CS 2000 - Compact when the CS LAN unit is 
upgraded. If the VMS machine is assigned a dynamic IP address and the IP address changes, 
messaging over the IP datalink is lost between the VMS and the CS 2000 - Compact when the IP 
address changes. 


The message desk UCD group connects calls to voice lines served by the VMS 
system. These lines are used to carry voice transmissions to and from the user's 
mailbox. Each mailbox is a unique address in the VMS for each user. 
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When a forwarded call is connected to a VMS voice line, the switch sends 
details of the call over the datalink. The call details are 


e user's DN 
e caller's DN (if available) 
e call type (call forward busy, call forward no answer, call forward all) 


e message desk number and line termination number of the line of the UCD 
group that the call is on. 


The caller can leave a voice message which the VMS records. When the caller 
hangs up, the call is released. The VMS notifies the switch through the datalink 
to activate the user's message waiting indicator. 


Retrieving messages from the voice message system 
The user retrieves messages by dialing the message desk DN or the call request 
retrieval code. The switch notifies the VMS of the incoming call and call 
information. The call information is the same as for TMS. The VMS 
terminates the call on the correct mailbox so the user can retrieve the messages. 
The VMS then notifies the switch to deactivate the message waiting indicator 
for the user. 


Message data stream 
The following example shows the format of an SMDI message: 


MDaaabbbbifffffff cccccce 


aaa 
Message desk number (001-063) 


bbbb 
Message desk terminal (0001-2047) 


fffffff 
DN of the hunt group 


Ccccccc 
calling station DN 


D - direct call 

A - forward all calls 

B - forward busy calls 

N - forward no answer calls 
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Communication between the switch and the message desk 


The switch supports the following two types of communication links to a 
message desk system: 


e voice lines, to which calls to the message desk are connected 


e a datalink, over which data messages are exchanged 


Voice connections to the message desk 
Each message desk supported by the switch is provided with a primary 
directory number (the additional secondary directory numbers may also be 
used) that is associated with a set of voice lines. Calls to the message desk 
directory numbers are distributed amongst the voice lines. 


In a VMS, the voice lines are connected to voice ports in the VMS system and 
calls are answered automatically. 


In a TMS, the voice lines are connected to a phone that is answered by an 
agent. 


Setting up voice connections to the message desk 

The DNs (directory numbers) for each message desk and the message desk 
lines to which the calls are directed are associated by datafilling them as a 
UCD group. 


The message desk lines are datafilled with both the UCD option and the SMDI 
option. It is recommended that the message desk lines within a SMDI UCD 
group have the Cutoff On Disconnect (COD) option. This ensures that when 
the caller hangs up, the line is immediately available to receive further calls. 


For ASPEN voice processing systems, COD should be used if ASPEN does 
not have the USL TIC cards. COD should not be used if ASPEN has the USL 
TIC cards that recognize the absence of loop current. 


Calls to the message desk DNs are distributed to the associated voice lines by 
UCD call processing. When a call is connected to a message desk voice line, 
SMDI processing sends a call detail message across the datalink. 


To activate and deactivate a voice connection 

For TMS, if the AUTOLOG option in table IBNFEAT is datafilled as N for no 
autolog, the message desk agent enters the UCD feature activation code to start 
receiving calls and the UCD feature deactivation code to stop receiving calls. 


For VMS, if the AUTOLOG option in table IBNFEAT is datafilled as Y for 
autolog, there is no activation or deactivation because the line is always 
available. 
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Message interchange over the datalink with the message desk system 
SMDI exchanges data messages with the message desk system over a datalink. 
The datalink connects the switch to the message desk system's central 
processing unit. 


SMDI sends 
The SMDI sends the following message types: 


1. Call detail messages (one for each call connected to a message desk voice 
line) identifying the following: 


e user's DN 
e caller's DN (if available) 


e call type (call forward busy, call forward no answer, call forward all, 
or direct call) 


e message desk number and line termination number of the line of the 
UCD group that the call is on 


2. Failure messages 
e Failure messages are described in Chapter 3. 
SMDI receives 
The SMDI receives the following message types: 
1. MWT on messages (activate message waiting) 
2. MWT off messages (deactivate message waiting) 


Details of the structure and content of each of the messages sent over the 
datalink are shown under "Message protocol" on page 3-2. 


Connections to multiple message desks 

SMDI can simultaneously support many message desks and messaging 
systems. SMDI can use up to 64 datalinks with the 1X67 or 1X89 
multi-protocol controller (MPC) cards, or any combination of the two. Each 
datalink supports one messaging system serving up to 999 message desks. 


Differences between message waiting and SMDI message waiting 
The message waiting capability offered on the switch can be used to leave: 


e aplease call me request (initiated when a caller, in the same customer 
group as the user, dials a call request activation code) 


e aplease call the message desk request (initiated by SMDI when a message 
waiting on message is received from a message desk system) 
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Message waiting and SMDI message waiting are compared in Table 1-3 and 
Table 1-4. The user is notified that a message is waiting by one of the 


following: 


e astuttered dial tone 


e amessage waiting lamp 


The feature activation codes required to set up and access message waiting are 
datafilled in table IBNXLA. Activation codes are used to do the following: 


e activate MWT (Call Request Activate (CRA)) 
e retrieve calls in the MWT queue (Call Request Retrieval (CRR)) 


e remove calls from the MWT queue (Call Request Delete Specific (CRDS) 
and Call Request Delete All (CRDA)) 


Table 1-3 Comparison of message waiting with SMDI message waiting (activation) 


Message waiting 


SMDI message waiting 


The caller calls the user, and receives busy 
signal, or the call is unanswered. 


The caller flashes or presses the Three-Way 
Calling (SWC) key to get special dial 


The caller dials the CRA access code, and gets 
confirmation tone. 


The caller goes on-hook. 


The switch adds the caller's DN to the MWT 
queue for the user, and activates the message 
waiting indicator for the user. 


The user forwards calls to the message desk 
UCD DN. 


The caller calls the user. 


The switch transmits call detail messages across 
the datalink to provide the message desk system 
with information about the call. 


The switch routes the caller to an appropriate 
message desk line. A message desk agent (TMS) 
or an automatic answering device (VMS) answers 
and records the message for the user. 


The caller goes on-hook. 


The message desk system sends a message 
waiting ON message over the datalink to the 
switch to activate the message waiting indicator 
for the user. 


The switch adds the message desk UCD group 
name to the message waiting queue for the user. 
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Table 1-4 Comparison of message waiting with SMDI message waiting (deactivation) 


Message waiting 


The message waiting indicator shows that a 
message has been left for the user. 


The user dials the CRR access code. If the user 
has an electronic business set (EBS) with display, 
then the caller's directory number is displayed on 
the top line of the user's set. 


The caller is rung. The caller answers and talks to 
the user. 


When the call is complete, the user goes 
on-hook. 


The caller's message is removed from the queue, 
and message waiting indicator is deactivated for 
the user. 


SMDI message waiting 


The message waiting indicator shows that a 
message has been left for the user. 


The user dials the CRR access code. If the user 
has an EBS with display then the message desk 
UCD group name (up to 16 characters) is 
displayed on the top line of the user's set. 


A call detail message is transmitted across the 
datalink to provide the message desk system with 
information about the call. 


The switch routes the user to an message desk 
line. A message desk agent (TMS) or an 
automatic answering device (VMS) answers and 
retrieves the messages for the user. 


The user goes on-hook. 


The message desk sends a message waiting 
OFF message over the datalink to the switch to 
deactivate the message waiting indicator for the 
user. 


The message desk UCD group name is removed 
from the message waiting queue, and message 
waiting indicator is deactivated for the user. 


Note: The message waiting indicator can remain 
on momentarily until the switch receives and acts 
upon the deactivation message. 


How SMDI interacts with other features 
This section describes what occurs if other features or conditions are present 


on calls that involve SMDI: 


e A station can have both MWT and SMDI message waiting activated 


against it. 


1-13 


Part of the processing of call request retrieval ensures that all messages are 
retrieved. To avoid losing messages, messages must be retrieved using the 
call request retrieval code. With this method of retrieval, the user receives 
message waiting indication until both message desk call waiting messages 
and regular call waiting messages are retrieved. If the user dials the 

message desk directly to retrieve messages, the control message from the 
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message desk will cancel the message waiting indication, even though 
there may be other regular messages waiting. 


e Acall forward validation termination call is considered a direct call to the 
message desk. 


e For an attendant console-extended call to the message desk, the source of 
the call is considered to be the calling party presented to the message desk. 


e The DN presented to the SMDI message desk is blank if the originator of 
the call is a trunk, attendant console, or station-controlled conference. 


e In the event of call forward chaining to a message desk, the called station 
information presented to the message desk is the first call forward base 
station in the chain. 


¢ In 3WC, when the third party is call forwarded and then transferred to a 
station that is forwarded to a message desk and the party invoking the call 
transfer hangs up before the called station is forwarded, then the 
information presented to the message desk is the original third party (the 
first call forward station before the transfer), and not the first call forward 
base station after the call transfer. 


If the party invoking the call transfer does not hang up before the called 
party is forwarded to a message desk, then the first call forward base station 
after the transfer is presented to the message desk. 


Note: This scenario only applies when the station forwarded to the 
message desk uses the Call Forward Don't Answer feature. 


Effect of restarts on SMDI operation 
The following conditions are true for warm and cold restarts, but not for a 
reload restart: 
e The message desk agents within an active UCD group are automatically 
logged in that group again. 
e Active datalinks in the transferring state are automatically brought up 
ready for use. 


e The message waiting indicator state on the user's station is preserved 
during cold restarts, even though the MWT messages queued against the 
user are lost. 


Note: Only warm restarts can preserve either message waiting 
messages or the message waiting indicator on the user's station. 


How DNSUPPR works 


DNSUPPR permits an office to suppress the appearance of the DNs of the 
forwarding-from station and the calling station on an individual SMDI basis. 
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Suppression is obtained by datafilling the DNSUPPR option fields in table 
SLLNKDEV. 


The DNSUPPR option has two subfields: CALLING and FWDING, 
representing the calling DN and the forwarding-from DN, respectively. For 
each of these subfields, it can be specified how DN suppression is to be 
handled for that DN. See "Datafilling table SLLNKDEV" on page 2-11 for 
details of datafill. 


The forwarding-from station DN may be either the original called station DN 
(default) or, if the LASTFWDN option has been assigned to the SMDI link, 
the last forwarding station DN. 


The DNSUPPR option will also cooperate with the LASTFWDN option and 
suppress a restricted forwarding-from DN regardless of whether the 
LASTFWDN option has been assigned. 


DN delivery with DNSUPPR option 


The following table lists the DNs that will be delivered to an SMDI, depending 
on which mode of suppression is in effect, and which DNs are restricted. Note 
that for indirect calls to an SMDI, if the forwarding-from DN is suppressed, no 
call information is delivered to the SMDI. 


Table 1-5 SMDI incoming call information with DNSUPPR options 


Forwarding 
Forwarding Calling Calling DN DN DN Delivered 
NEVER NEVER Unrestricted Unrestricted Both 
Restricted 
Restricted Unrestricted 
Restricted 
CONDITNL Unrestricted Unrestricted 
Restricted 
Restricted Unrestricted Forwarding 
Restricted 
INDIRECT Unrestricted Unrestricted 
Restricted 
Restricted Unrestricted 
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Table 1-5 SMDI incoming call information with DNSUPPR options 


Forwarding Calling Calling DN 
COMPCND Unrestricted 
Unrestricted 
Restricted 
Restricted 


COMPNODIR Unrestricted 


Unrestricted 


Forwarding 
DN 


Restricted 
Unrestricted 
Restricted 


Unrestricted 


Restricted 


Unrestricted 


Restricted 


DN Delivered 


Both 
Both 


Forwarding 


Note: lf the 
Calling DN 
and the 
Forwarding 
DN are in the 
same 
customer 
group, both 
the 
Forwarding 
DN and the 
Calling DN 
will be 
passed. 


Forwarding 


Note: lf the 
Calling DN 
and the 
Forwarding 
DN are in the 
same 
customer 
group, both 
the 
Forwarding 
DN and the 
Calling DN 
will be 
passed. 


Both 


Both 
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Table 1-5 SMDI incoming call information with DNSUPPR options 


Forwarding Calling 
CONDITNL NEVER 
CONDITNL 


Calling DN 


Restricted 


Restricted 


Unrestricted 


Restricted 


Unrestricted 


Restricted 


Forwarding 
DN 


Unrestricted 


Restricted 


Unrestricted 
Restricted 
Unrestricted 
Restricted 
Unrestricted 
Restricted 


Unrestricted 


DN Delivered 


Forwarding 


Note: lf the 
Calling DN 
and the 
Forwarding 
DN are in the 
same 
customer 
group, both 
the 
Forwarding 
DN and the 
Calling DN 
will be 
passed. 


Forwarding 


Note: lf the 
Calling DN 
and the 
Forwarding 
DN are in the 
same 
customer 
group, both 
the 
Forwarding 
DN and the 
Calling DN 
will be 
passed. 


Both 
Neither 
Both 
Neither 
Both 


Neither 


Forwarding 
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Table 1-5 SMDI incoming call information with DNSUPPR options 


Forwarding 


Calling 


INDIRECT 


COMPCND 


COMPNODIR 


Calling DN 


Unrestricted 


Restricted 


Unrestricted 
Unrestricted 
Restricted 
Restricted 
Unrestricted 
Unrestricted 


Restricted 


Restricted 


Forwarding 
DN 


Restricted 
Unrestricted 
Restricted 
Unrestricted 
Restricted 
Unrestricted 
Restricted 
Unrestricted 
Restricted 
Unrestricted 
Restricted 


Unrestricted 


Restricted 


DN Delivered 
Neither 
Forwarding 
Neither 
Forwarding 
Neither 
Both 
Neither 
Both 
Neither 
Both 
Neither 


Forwarding 


Note: lf the 
Calling DN 
and the 
Forwarding 
DN are in the 
same 
customer 
group, both 
the 
Forwarding 
DN and the 
Calling DN 
will be 
passed. 


Neither 


Interactions and limitations of DNSUPPR 


Certain combinations of datafill in table SELNKDEV for the DNSUPPR 
option cause interactions and limitations to occur at the subscriber's message 


297-2051-104 Preliminary 13.01 September 2004 


Learning the basics of SMDI 1-19 


waiting indicator (MWI). The following table lists these datafill combinations 
and the resulting effects. 


Table 1-6 DNSUPPR interactions and limitations 


DNSUPPR datafill Effect 


FWDING=CONDITNL INTERACTION. SMDI cannot update the MWI of a subscriber whose DN 
is restricted. Also, if the forwarding DN is restricted, no call information is 
delivered to the SMDI. 


CALLING=CONDITNL INTERACTION. SMDI will be unable to allow a subscriber whose DN is 
restricted to retrieve messages. 


CALLING=CONDITNL LIMITATIONS. A restricted forwarding DN will still be presented to the 
FWDING=NEVER SMDI, and the SMDI will be able to activate the subscriber's MWI. 


If a subscriber whose DN is restricted, calls the SMDI directly to retrieve 
messages from the subscriber's MWI, no calling DN is presented to the 
SMDI. Since the subscriber's DN is unknown, the subscriber will not be 
able to retrieve these messages, and the SMDI will not be able to activate 
the subscriber's MWI. In this case, the subscriber can use Calling Number 
Delivery Blocking (CNDB) to toggle the suppression on the subscriber's 
DN, when calling to retrieve messages from the SMDI system. 
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2 Datafilling for SMDI 


Datafill 


The following tables require datafill for Simplified Message Desk Interface 
(SMDI). 


Table 2-1 Required datafill tables for SMDI 
Table 
SLLNKDEV 
UCDGRP 
DNROUTE 
IBNXLA 
IBNLINES 
IBNFEAT 
MPC * 
MPCLINK * 


* Tables and MPC and MPCLINK are not needed for a CS 2000 - Compact. 


SMDI enhancements 


The enhancement of the SMDI performance in the BCS30 software, allows the 
NTIX89AA device controller card for the SMDI datalinks. 


The enhancement of the SMDI performance in the NAO13 software release 
allows the FX30 device controller card for the SMDI datalinks. 


The NAO14 software release enhances the blocking of restricted number 
delivery to the SMDI by adding two suboptions to the option DNSUPPR 
CALLING in table SELNKDEV: COMPCND and COMPNODIR. 


DMS-100 Family MDC SMDI Setup and Operation SN04 and up 


2-2 Datafilling for SMDI 


Feature A59037993, “SMDI over TCP/IP” in the SN04 release allows SMDI 
messages to be transmitted over TCP/IP between a CS 2000 - Compact and a 
voice mail system (VMS). 


The following are required office parameters that must be engineered (in table 
OFCENG) for the SMDI datalinks: 


e GUARANTEED_TERMINAL_CPU_SHARE for the 1X67 link 
e AUXCP_CPU_SHARE for the 1X89 link 


Note: Configuring these office parameters is not needed for 
CS 2000 - Compact offices. 


For information on office parameters refer to the Office Parameters Reference 
Manual. 


With BCS31 software, the DNSUPPR option is available, through table 
SLLNKDEYV, provided that the directory number (DN) fields in tables 
NETNAMES, DNGRPS, and DNATTRS have been set to SUPPRESS. Refer 
to the Customer Data Schema Reference Manual. 


Note: The blocking of restricted DNs is handled in the same manner for 
both nodal and network call types. A network call type is a call type with 
Integrated Services Digital Network (ISDN) user part (ISUP) or primary 
rate interface (PRI) over the span of the entire call. 


In addition, a Custom Local Area Signaling Services (CLASS) line may have 
the Calling Number Delivery Blocking (CNDB) option, which allows an 
originating subscriber to control, on a call-by-call basis, the availability of the 
subscriber's DN. 


NT1X89AA card 


For SMDI applications, the multi-protocol controller (MPC) card is used 
alone. With increased bandwidth, performance, and reliability, it enhances the 
data communication for SMDI by providing the following: 


e data rates from 300 bits to 19.2 kbit/s 


e buffering: when the SMDI traffic load increases, the messages are buffered 
into the MPC to central control (CC) buffer. The MPC can buffer up to 250 
kilobytes of data. Due to message compression by the MPC, each message 
takes 6 bytes of data, and thus, 250 kbytes is over 40 000 messages. 


e software to control the input and output of data; it reduces DMS CC real 
time for input/output 


e SMDI load and overload controls 
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e support for two SMDI links per card 


e support for 64 SMDI datalinks, and ten-digit DNs for outgoing and 
incoming SMDI messages 


MPC datafill for SMDI 
The following tables require entries for the MPC datafill for SMDI: 


e Table MPC defines the MPC card to the DMS, and it includes the MPC 
number, the input/output controller (IOC) shelf and circuit number, and the 
download file name. 


e Table MPCLINK identifies the MPC links to the DMS, and it includes 
protocol (AS YNC) and application (APLDEFN). 


FX30AA card 
The NAO13 software release introduces the card FX30AA for the Input Ouput 
Multiprotocol Controller (OM MPC) to replace IOC hardware in the 
DMS-100 switch. Before this enhancement, the IOM MPC entry in the table 
SLLNKDEYV is 1X89. The 1X89 uses the MPC software to support SMDI. 
The IOM MPC now uses the FX30 card 


IOM MPC datafill for SMDI 
The tables that follow require entries for IOM MPC datafill for SMDI: 


e Table MPC defines the IOM MPC card in the DMS-100 switch and the 
table includes the MPC number, the input or output (IOC) controller shelf, 
the circuit number, and the download file name 


e Table MPCLINK identifies the MPC links in the DMS-100 switch and the 
table includes the protocol (AS YNC) and application (APLDEEFN) 


SMDI over TCP/IP 
The SN04 release allows a CS 2000 - Compact to send SMDI messages over 
a TCP/IP datalink to a VMS. No datafill is required for tables MPC or 
MPCLINK. Software optionality control (SOC) SMDIO001 must be activated 
to enable provisioning of a TCP device in table SLLNKDEV. 


Required datafill 


The following table identifies, in summary, the tables and the fields in the 
tables that require datafill for SMDI. 


MPCNO Enter the MPC number of the device 
associated with SMDI. 


MPCIOC Enter the MPC IOC shelf number associated 
with MPC SMDI card. 
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lIOCCCT 
EQ 


DLDFILE 


MPCLINK MPCNO 


LINKNO 


PROTOCOL 
LINKNABL 
APLDEFN 
SLLNKDEV DEVNAME 
DEVTYPE 


XFERS 
OPTION 
NUMDIGS 
OPTION 
CALLING 


FWDING 


Enter the IOC circuit number. 


Enter 1X89AA for the MPC card. 
Enter FX30AA for the FX card. 


Enter the MPCAXXYY which is the name of 
the 8-character download file for SMDI. 
XXYY represents the BCS load designation. 


for the MPC card. 
Enter IOM$LOAD for the FX30 card. 


Enter MPC number of the device associated 
with SMDI. 


Enter port 2 or 3 of the MPC card (for the 
MPC card.) 


Enter port 3 of the FX30 card (for the FX30 
card.). 


Enter ASYNC. 

Enter a value from 0 to 32 765. 
Enter SMDI. 

Enter a valid device name. 


Enter 1X89 for the MPC card. Enter FX30 for 
the FX30 card. Enter TCP and the IP address 
and port number of the VMS for a 

CS 2000 - Compact. 


Note: If DEVTYPE is 1X89, then subfields 
MPCNO and LINKNO are presented. If 
DEVTYPE is TCP, then subfields 
REM_SMDR_IP_ADDR and PORT are 
presented. 


Enter SMDIDATA. 

Enter NUMOFDIGS. 

Enter 7, 10, or var (variable). 
Enter DNSUPPR. 


Enter NEVER, CONDITNL, INDIRECT, 
NODIRECT, COMPCND, or COMPNODIR. 


Enter NEVER or CONDITNL. 
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UCDGRP OPTIONS 


DNROUTE AREACODE, 
OFCCODE, and 
STNCODE 


IBNXLA TRSEL 
FEATURE 


(refinement of 
TRSEL=FEAT) 


Note: Table IBNLINES and table IBNFEAT should be filled through the Service 
Order system (SERVORD). See the service orders section of this document for 


examples. 


IBNLINES OPTION 


IBNFEAT DF 


FEATURE 


Before you begin datafill 


This section describes recommendations, requirements and restrictions for 
datafilling the message desk UCD group and the user station. 


Enter UCD_SMDI to designate this uniform 
call distribution (UCD) group as the SMDI 
message desk. 


Enter a valid directory number from table 
TOFCNAME. 


Enter FEAT. 


Enter UCDA, UCDD, CRA, CRR, CRDA, or 
CRDS. 


Enter UCD. Agents within this UCD group 
must have this option to become UCD 
agents. 


Enter SMDI. Agents within a UCD group must 
have the SMDI option to indicate that their 
UCD lines have the SMDI feature. 


Enter SMDI. 


Recommendations for the message desk UCD group 


The list that follows describes recommendations for the datafill of the message 
desk in the UCD group: 


The agents within the UCD group should have the Cutoff On Disconnect 
(COD) option in table IBNLINES. 


For ASPEN voice processing systems, COD should be used if the ASPEN 
does not have the USL TIC cards. COD should not be used if ASPEN has 
the USL TIC which recognize the absence of loop current. 


The assignment of multiple desk numbers per datalink should be done 
during off-hours so that any UCD group handling call retrievals is not 
abruptly affected by this change. 


Changing from multiple desk numbers to a single desk number should be 
done during off-hours so that any UCD group handling call retrievals is not 
abruptly affected by this change. 
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Requirements for message desk UCD group 
SMDI supports a maximum of 63 datalinks to transfer messages. Each datalink 
supports a maximum of 999 message desks. For the switch, each UCD group 
is a message desk and each UCD group has a message desk number. Table 
DNROUTE must have the assignment of the UCD feature with the primary 
and secondary directory numbers. 


Restrictions for the message desk UCD group 
The list that follows describes the restrictions for the datafill for the message 
desk in the UCD group: 


The SMDI option cannot be added to a UCD group if any agents in the 
UCD group are active. 


The SMDI option cannot be modified for a UCD group if any agents in the 
UCD group are active. 


Use SERVORD to provision the line in a UCD group. This action 
provisions table IBNFEAT. 


Requirements for the user station 
The list that follows describes the requirements for the datafill for the user 
station: 


Datafill errors 


To forward calls to the message desk the user must have one of the call 
forward features: call forward busy, call forward don't answer, or call 
forward all. 


To enable the message waiting indicator (MWI) on the station to be turned 
on, the user must have the Message Waiting (MWT) feature provisioned 
through SERVORD. The user can define some other means of message 
waiting indicator other than the standard MWT light or stuttered dial tone. 
In this case, the user's station does not have to be datafilled with the MWT 
option. However, if the message desk attempts to activate or deactivate 
MWT through the datalink without the MWT option, an error results and 
a log (SMDI100) will be generated. 


If the datafill is not correct, SMDI will not function properly. The following 
examples of incomplete datafill will give the results described: 


No SMDI option in table UCDGRP, and table DNROUTE is not datafilled 


If the UCD_SMDI option is not assigned to the UCD group in table UCDGRP, 
and table DNROUTE is not datafilled, then a direct call to the message desk 
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will receive the defined treatment and a call request retrieve call will go to the 
night service route. 


e No SMDI option in table UCDGRP 


If the UCD_SMDI option is not assigned to the UCD group in table 
UCDGRP, but table DNROUTE is datafilled with the UCD group DN, then 
a direct call to the message desk and a Call Request Retrieval (CRR) will 
terminate on an active UCD group member. However, no SMDI messages 
will be transmitted across the datalink. If there are no active UCD group 
members, then the direct call and the CRR call will go to the night service 
route. 


e NoSMDI option in table UCDGRP, and tables DNROUTE and UCDGRP 
are not datafilled 


If there is no UCD group defined in table UCDGRP, a direct call and a 
CRR call will be routed to the defined treatment. The user should activate 
Call Request Delete Specific (CRDS) or Call Request Delete All (CRDA) 
to reset the message waiting indicator. 


Datafilling table MPC 


The following procedure shows the datafill for table MPC. The MPC table 
defines the MPC card 1X89 or FX30 for the SMDI datalinks to the switch. For 
the SMDI application, the datafill includes the MPC number, the MPCIOC 
shelf, the IOC circuit number, the card code (1X89 or FX30), and the 
download file name. For SMDI datalinks that use an MPC, the download file 
(DLDFILE) field is MPCAxxyy, where A represents ASYNC, and xxyy 
represents the BCS load designation. For the FX30 card, enter IOM$LOAD 
for the download file (DLDFILE) field. 


Table MPC must be datafilled before tables MPCLINK and SLLNKDEV. This 
procedure contains only those fields that apply to SMDL. Refer to the Customer 
Data Schema Reference Manual for a description of the other fields. 


Table 2-2 Datafilling table MPC 


Field 
MPCNO 


MPCIOCG 


Subfield Explanation and action 


Multi-protocol controller number 

Enter the number of MPC used for SMDI. Valid entries are from 
0 to 255. 

Multi-protocol controller input/output controller shelf 


Enter the number associated with the (MPC or FX30) SMDI 
card. Valid entries are from 0 to 19. 
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Table 2-2 Datafilling table MPC 


lIOCCCT 


EQ 


DLDFILE 


Field Subfield 


Explanation and action 


Input/output controller circuit number 

Enter the slot position on the IOC shelf multiplied by 4, then 
subtract 1. Valid entries are from 0 to 35. 

Equipment product engineering code 

Enter the NT PEC for the MPC or FX30 card. Enter 1X89AA or 
1X89BA, or FX30. 

Download file 


Enter the 8-character download file name for SMDI. Enter 
MPCAxxyy for an 1X89. MPCA represents MPC async, and 
xxyy represents the BCS load designation. 


Enter IOM$LOAD for DLDFILE for the FX30 card. 


An example of the datafill for table MPC follows: 


> 


TABLE: MPC 


MPCNO: 


MPCIOC: 
> 
IOCCCT: 
> 

EQ: 

> 
DLDFILE: 


> 


User input 


System prompt 


table mpc 


add 


10 


16 


1x89aa 


mpca30bh 
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Datafilling table MPCLINK 


The following procedure shows the datafill for the table MPCLINK. The table 
MPCLINK must have the entries for the SMDI datalinks for the MPC card 
1X89 or FX30. Table MPCLINK identifies the datalinks to the DMS switch. 
For the SMDI application, the following subfields should be datafilled in table 
MPCLINK: 


e PROTOCOL 
e APLDEFN 


In addition, table MPCLINK has the following two parameters: 
e LIIDLY 
e L2IDLY 


These parameters represent the input delay (in 10 milliseconds) for layerl and 
layer2, respectively. LIIDLY defaults to 100 and L2IDLY defaults to 200. 
Thus, the maximum time that the MPC can delay sending messages to the 
central control (CC) is 300 (10 millisecond units) or 3 seconds. LIIDLY and 
L2IDLY only delay the MPC input during periods of low link occupancy. 
However, if three seconds is an unacceptable delay, then these parameters may 
be changed to smaller values. 


LIIDLY must be less than L2IDLY, and for SMDI, LIIDLY cannot be set to 0. 
The 0 value for LIIDLY indicates that the input from the MPC to the CC 
should be sent on a character by character basis. 


The BAUDRATE parameter defaults to 1200. However, the MPC supports 
baud rates of up to 19.2 kbit/s. 


The MPCLINK table must be datafilled before table SELNKDEV. This 
procedure contains only those fields that apply to SMDL. Refer to the Customer 
Data Schema Reference Manual for a description of the other fields. 


Table 2-3 Datafilling table MPCLINK 


Field 
LINKKEY 


Subfield Explanation and action 


Link key field 
This key field is comprised of subfields MPCNO and LINKNO. 


MPCNO Multi-protocol controller number 


Enter the MPC number, the same value datafilled in table MPC. 
Valid entries are from 0 to 255. 
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Table 2-3 Datafilling table MPCLINK 


Field Subfield 
LINKNO 
PRTCLDAT 
PROTOCOL 
LINKNABL 
APLDEFN 


Note: The purpose of the LINKNABL 


service. To prevent the MPC card and 


Explanation and action 


Link number 


Enter the MPC link number for the SMDI application with 
ASYNC protocol. The valid entries are 0 to 3 for the MPC card. 


Enter the FX30 link number for the SMDI application with 
ASYNC protocol. The valid entry is 3. 


Protocol data 


This field is comprised of subfields PROTOCOL, LINKNABL, 
and APLDEFN. 


Protocol 


Enter the link protocol. It must be consistent with the download 
file specified in table MPC. Enter ASYNC. 


Link enable 


Enter the number of minutes, in multiples of 5, a link is system 
busied and returned to service when the link fails to enable. 
Valid entries are from 0 to 32 767. (See Note.) 


Application definition 


Enter the name of the application. Enter SMDI. 


capability is to re initialize mechanisms on the MPC card in an 


attempt to enable the link. If this capability is not desired, the LINKNABL subfield can be datafilled as 
0, which disables the function. If the LINKNABL subfield is datafilled with a non-zero value and one 

link is enabled and the second link has reached the LINKNABL timeout threshold (that is, the link has 
been system busied), the enabled link and the MPC card will become system busied and returned to 


the enabled link from becoming system busied and returned to 


service, the LINKNABL subfield can be datafilled with 0 for the system busy link. 


An example of the datafill for table MPCLINK follows: 


System prompt 
> 

TABLE: MPCLINK 
> 

LINKKEY: 


> 


User input 


table mpclink 


add 


12 
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System prompt User input 
LINKALM: 

> y 
PROTOCOL: 

> async 
LINKNABL: 

> 55 
PARM: 

> apldefn 
APLDEFN: 

> smdi 
PARM: 

> $ 
STRID: 

> $ 


Datafilling table SLLNKDEV 
The following procedure shows the datafill for table SLLNKDEV. Table 
SLLNKDEYV is used to specify characteristics of datalinks used by the CI 
command LNKUTIL. The SMDILNK level is also used for TCP/IP datalinks. 


All devices must be datafilled in table SLLNKDEYV before they are connected 
in the command interpreter increment LNKUTIL. These devices must be 
datafilled in table TERMDEYV before they can be datafilled in table 
SLLNKDEV. TCP/IP datalinks for CS 2000 - Compact are automatically 
connected upon datafill completion and do not require datafill in table 
TERMDEV. 


There is no dependency between the table control software and the SLLNK 
software. An entry in table TERMDEV can be manipulated independently of 
any corresponding entry in table SLLNKDEV. The only restriction imposed is 
that the datalink device must be datafilled in table TERMDEYV before it can be 
datafilled in table SLLNKDEYV, and the device must be datafilled in table 
SLLNKDEYV before it can be accessed by LNKUTIL. 
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This procedure contains only those fields that apply to SMDI. Refer to the 
Customer Data Schema Reference Manual for a description of the other fields. 


Table 2-4 Datafilling table SLLNKDEV 


Field Subfield Explanation and action 

DEVNAME Device name 
Enter the 1- to 16-character device name used in SMDILNK. 

DEVTYPE Device type 
Enter the type of device. Enter 1X89 for the MPC card. Enter 
FX30 for the FX30 card. Enter TCP for CS 2000 - Compact 
offices. 
Note 1: lf the field DEVTYPE is 1X89, the subfields MPCNO 
and LINKNO require datafill before the datafill in the field 
XLATION. 
Note 2: lf field DEVTYPE is TCP, subfields 
REM_SMDR_IP_ADDR and PORT require the IP address and 
port number of the VMS. 

XLATION Translation 
Enter the translation used for outgoing and incoming datalinks. 
Enter NONE or BCDTOASCII. 

PROTOCOL Protocol 
Enter the protocol expected by the datalink and the switch 
concerning the connection and starting messages, as well as 
any leading byte information required. Valid entries are NONE 
and X400. 

DRECTION Direction 
Enter the direction that the data travels through the datalink. 
Enter INOUTLK for in/outlink. Enter INOUTLNK for 
CS 2000 - Compact offices. 

XFERS Transfers 
Enter the report types that are allowed on the datalink. Enter 
SMDIDATA for SMDI I/O communication. 

OPTION Options 

Enter NUMOFDIGS (number of digits) for the number of digits 
for SMDIDATA. Or enter COMMON to select a common 
message desk number for each SMDI link to be used during 
CRR. 


If NUMOFDIGS is the option, datafill the subfield NUMDIGS. 
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Table 2-4 Datafilling table SLLNKDEV 


Field | Subfield | Explanation and action 


NUMDIGS Number of digits 


Enter the number of digits in the DN to send to the voice 
messaging system (VMS). Valid entries are 7, 10, or var 
(variable). 


OPTION Option 
Enter DNSUPPR for DN suppression. 


If COMMON is the option, datafill subfield DESKNUM. 


DESKNUM Desk number 
Enter a number from 1 to 999 to indicate the common message 
desk number for CRR. 

CRRTYPE Call request retrieval type 
Enter ALL if all link users are to use the common message desk 
during CRR. Or enter NETWORK if only subscribers outside 
the host node are to use the common message desk during 
CRR. 


If DNSUPPR is entered, subfields CALLING and FWDING are presented: 


DMS-100 Family MDC SMDI Setup and Operation SN04 and up 


2-14 Datafilling for SMDI 


Table 2-4 Datafilling table SLLNKDEV 


Field | Subfield | Explanation and action 


CALLING Calling directory number suppression 


Enter whether the calling DN is suppressed when presented to 
the SMDI. Valid entries are NEVER, CONDITNL, INDIRECT, 
NODIRECT, COMPCND, and COMPNODIR. 


Enter NEVER if the calling DN is never suppressed. 


Enter CONDITNL if the calling DN is conditionally suppressed. 
That is, the calling DN is suppressed if it is restricted. 


Enter INDIRECT if all indirect calls are suppressed. 


Note: lf INDIRECT is chosen, it implies that on indirect calls, 
no DN suppression is performed on the calling DN. 


Enter NODIRECT if the calling DN is always delivered, 
regardless of its privacy status. 


Enter COMPCND 


e for an indirect call, the calling DN is suppressed only if the 
calling DN and the forwarding DN are not in the same 
customer group 


e for adirect call, the calling DN is delivered if the calling DN 
is unrestricted or if the network of the calling DN and the 
network of the SMDI_LINK are the same 


Enter COMPNODIR 


e for an indirect call, the calling DN is suppressed only if the 
calling DN and the forwarding DN are not in the same 
customer group 


e for a direct call, if the calling DN is always delivered 


FWDING Forwarding directory number suppression 


Enter whether the forwarding DN is suppressed when 
presented to the SMDI. Valid entries are NEVER and 
CONDITNL. 


Enter NEVER if the forwarding DN is never suppressed. 


Enter CONDITNL if the forwarding DN is conditionally 
suppressed. That is, the forwarding DN is suppressed if it is 
restricted. 
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An example of the datafill for table SLLNKDEV follows: 


System prompt 


> 


TABLE: SLLNKDEV 


> 
DEVNAME: 
> 

DEVICE: 

> 
XLATION: 


> 


PROTOCOL: 


> 


DRECTION: 


XFER: 


OPTION: 
> 
NUMDIGS: 
> 

OPTION: 
> 
CALLING: 
> 
FWDING: 


> 


User input 


table silnkdev 


add 


smdi5 


1x67 (Refer to Note 1.) 


none 


none 


inoutlk 


smdidata 


numofdigs 


dnsuppr (Refer to Note 2.) 


indirect 


conditnl 
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System prompt User input 
OPTION: 

> $ 

XFER: 

> $ 


Note 1: Enter HS1X67 if field PEC in table TERMDEV is 1X67FA. 


Note 2: In this example, the SMDI device SMDI5 will suppress restricted 
forwarding DNs and all calling DNs on indirect calls, and will not perform 
any DN suppression on direct calls. 


Datafilling table UCDGRP 
Table UCDGRP defines the message desk number for each UCD group. 


Avoiding MWT error using table UCDGRP 

The retrieval methods CRR or the depression of the MWT key retrieve the 
SMDI messages and terminate on a retrieval message desk.To prevent the 
appearance of the retrieval message desk number in the message, the entry in 
the NSROUTE field in the table UCDGRP must go to an IBN route. Table 
IBNRTE includes the N selector to point to a loop-around trunk and a DMI 
(digit manipulation index) to point to table DIGMAN. The entry in table 
DIGMAN includes the directory number of another UCD group to use for 
message retrievals. 


Note: ISUP (Integrate Services Digital Network user part) or PRI (primary 
rate interface) loop-around trunks should be used in this scenario. 


This procedure contains only those fields that apply to SMDI. Refer to the 
Customer Data Schema Reference Manual for a description of the other fields. 


Table 2-5 Datafilling table UCDGRP 


Field Subfield Explanation and action 


UCDNAME Uniform call distribution name 


Enter the 1- to 16-character name assigned to UCD group. 


ACD Automatic Call Distribution 
Enter N because Automatic Call Distribution is not supported. 
CUSTGRP Customer group name 


Enter the 1- to 16-character name of the customer group to 
which the UCD group belongs. 
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Field 
UCDRNGTH 


THROUTE 


NSROUTE 


PRIOPRO 


MAXPOS 


Subfield 


TABID 


INDEX 


TABID 


INDEX 
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Explanation and action 


Uniform call distribution ringing threshold 


Enter the ringing threshold, in one-second intervals, after which 
an unanswered call to a UCD agent is forwarded to the route 
specified in field THROUTE. Valid entries are from 0 to 63. 


Threshold route 


Consists of subfields TABID and INDEX. Specifies the route in 
tables IBNRTE, IBNRT2, IBNRT3, OFRT, OFR2, or OFR3 to 
which overflow and time-outs are routed. 


Table name 


Enter the table name to which overflow and time-outs are 
routed. Valid entries are IBNRTE, IBNRT2, IBNRT3, OFRT, 
OFR2, and OFR3. 


Index 


Enter the number assigned to the route list to which overflow 
and time-outs are routed. Valid entries are from 1 to 1023. 


Night service route 


Consists of subfields TABID and INDEX. Specifies the route in 
tables IBNRTE, IBNRT2, IBNRT3, OFRT, OFR2, or OFR3 to 
which calls for the UCD group in night service mode are routed. 


Table name 


Enter the table name to which night service calls are routed. 
Valid entries are IBNRTE, IBNRT2, IBNRT3, OFRT, OFR2, and 
OFR3. 


Index 


Enter the number assigned to the route list to which night 
service calls are routed. Valid entries are from 1 to 1023. 


Priority promotion time-out 


Enter the maximum time, in seconds, a call can wait in a queue. 
Valid entries are from 0 to 255 seconds. 


Maximum number of positions 


Enter the maximum number of UCD agent positions that can be 
active at one time. Valid entries are from 0 to 1023. 
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Table 2-5 Datafilling table UCDGRP 


Field 
DBG 


DEFPRIO 


RLSCNT 


MAXWAIT 


MAXCQSIZ 


OPTIONS 


Subfield 


SMDI_LINK 


SMDI_DESK_NO 


MCOS_LIST 


Explanation and action 


Delayed billing 


Enter Y if billing starts when the call is answered by a UCD 
agent. Enter N if billing starts when the caller receives recorded 
announcement. 


Default priority 


Enter the default priority number which is applicable to local 
calls terminating upon the primary UCD number. Valid entries 
are from 0 to 3. 


Release count 


Enter the maximum number of calls which terminate on a UCD 
station, but are not answered. After this number is reached, the 
agent is automatically deactivated from the UCD group. Valid 
entries are from 0 to 31. 


Maximum wait time 


Enter the maximum time, in seconds, that a call should have to 
wait in the incoming call queue before being answered. Valid 
entries are from 0 to1800. 


Maximum call queue size 


Enter the maximum number of calls that can be in the incoming 
call queue. Valid entries are from 0 to 511. 


Options 
Enter UCD_SMDI so the number is part of a SMDI UCD group. 


SMDI link name 
Enter the terminal designation defined in table SLLNKDEV. 


SMDI message desk number 


Enter the message desk number. Valid entries are from 1 to 
999. 


Message class of service list 


Enter up to four class of service names for the messages. 
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An example of datafill for table UCDGRP follows: 


System prompt User input 
> table ucdgrp 


TABLE: UCDGRP 


> add 
UCDNAME: 

> messdesk 
ACD: 

> n 
CUSTGRP: 

> cust1 
UCDRNGTH: 

> 5 
TABNAME: 

> ofrt 
INDEX: 

> 4 
TABNAME 

> ionrte 
INDEX: 

> 7 
PRIOPRO: 

> 99 
MAXPOS: 

> 10 
DBG: 

> y 
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System prompt 


DEFPRIO: 


> 
RLSCNT: 

> 

MAXWAIT: 

> 

MAXCQSIZ: 

> 

OPTION: 

> 

SMDI_LINK: 

> 
SMDI_DESK_NO: 
> 

MCOS_LIST: 

> 

MCOS_LIST: 

> 

OPTION: 


> 


User input 


120 


90 


ucd_smdi 


smdi5 


classa 


Datafilling table DNROUTE 


The following procedure shows the datafill for table DNROUTE. The primary 
and secondary directory numbers are assigned to a UCD group in table 


DNROUTE. 
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This procedure contains only those fields that apply to SMDI. Refer to the 
Customer Data Schema Reference Manual for a description of the other fields. 


Table 2-6 Datafilling table DNROUTE 


Field 
AREACODE 


OFCCODE 


STNCODE 


DNRESULT 


Subfield 


DN_SEL 


FEATURE 


UCDGRP 


DNAREA 


DNTYPE 


TOLLPRIO 


Explanation and action 


Serving number plan area 


Enter the serving NPA of the DN. 


Office code digit register 
Enter the NNX code of the directory number. 


Station code 
Enter the DEFG digits of the directory number. 


Directory number results 


This field is comprised of the subfields DNSEL, FEATURE, 
UCDGRP, and DNAREA. 


Directory number selector 


Enter the directory number selector FEAT. 


Feature 
Enter the feature UCD. 


Uniform call distribution group 

Enter the 1- to 16-character name for this UCD DN, previously 
datafilled in table UCDGRP, field UCDNAME. 

Directory number area 

This subfield is composed of subfields DNTYPE, TOLLPRIO, 
MEMNO, and DNPRIO. 

Directory number type 


Enter PRIM if the DN is the primary UCD DN for this UCD 
group, and complete subfield TOLLPRIO. Enter SUPP ifthe DN 
is one of the supplementary DN(s) for this UCD group, and 
complete subfields MEMNO and DNPRIO. 


Toll priority 


Enter the priority of toll calls terminating on the primary UCD 
DN. Valid entries are from 0 to 3. The highest priority is zero. 
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Table 2-6 Datafilling table DNROUTE 


| Subfield | Explanation and action 


Member number 


Enter the UCD member number of this DN in this UCD group. 
Valid entries are from 1 to 4. 


PNPRIO Directory number priority 


An example of the datafill for table DNROUTE follows: 


Enter the priority of calls terminating on this UCD DN. Valid 
entries are from 0 to 3. 


System prompt 
> 

TABLE: DNROUTE 
> 

AREACODE: 

> 

OFCCODE: 

> 

STNCODE: 

> 

DN_SEL: 

> 

FEATURE: 

> 

UCDGRP: 

> 

DNTYPE: 


> 


User input 


table dnroute 


add 


613 


722 


4980 


feat 


ucd 


messdesk 


prim 
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System prompt User input 
TOLLPRIO: 
> 0 


Datafilling table IBNFEAT 


The following procedure shows the datafill for table IBNFEAT. Features are 
assigned to lines in table IBNFEAT. Table UCDGRP must be datafilled before 
table IBNFEAT for SMDI, because the subfield UCDGRP must contain the 
same name assigned to the field UCDNAME in table UCDGRP. 


This procedure contains only those fields that apply to SMDI. Refer to the 
Customer Data Schema Reference Manual for a description of the other fields. 


Table 2-7 Datafilling table IBNFEAT 


Field 
LEN 


DATA 


Explanation and action 


Line equipment number 


This field is comprised of subfields SITE, FRAME, UNIT, 
DRAWER, and CIRCUIT. 


SITE Site 


Enter the site name of the remote location. If left blank, the 
default value is HOST. 


FRAME Frame number 


Enter the line module frame number. Valid entries are from 0 to 
99. 


UNIT Unit number 


Enter the unit number of the line module to which the line is 
assigned. Valid entries are 0 and 1. 


DRAWER Drawer number 


Enter the number of the line drawer or line subgroup to which 
the line is assigned. Valid entries are from 0 to 19. 


CIRCUIT Line card circuit number 


Enter the line card circuit number. Valid entries are from 0 to 31. 


Data 


This field is comprised of subfields DF, LINENO, UCDGRP, 
and AUTOLOG. 
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Table 2-7 Datafilling table IBNFEAT 


Field | Subfield | Explanation and action 


DF Data feature 
Enter the data feature SMDI. 


LINENO Line number 
Enter the line number in the SMDI UCD group. Valid entries are 
from 1 to 1024. 

UCDGRP Uniform call distribution group name 
Enter the 1- to 16-character UCD group name assigned in table 
UCDGRP. 

AUTO_LOG Automatic login 


Enter Y if the line is to log automatically into the UCD group. 
Enter N if the line is to log manually into the UCD group. 


An example of datafill for table IBNFEAT follows: 


System prompt User input 
> table ibnfeat 
TABLE: IBNFEAT 

> add 

LEN: 

> host 02 1 00 06 
DNNO: 

> 0 

DF: 

> smdi 
FEATURE: 

> smdi 
LINENO: 

> 2 

UCDGRP: 
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System prompt User input 
> messdesk (See Note.) 
AUTOLOG: 


> 


Note: Must be same name as assigned in table UCDGRP. 
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3 Setting up and maintaining datalinks 


Datalink used between the DMS-100 switch and the message desk 
A multilink American Standard Code for Information Interchange (ASCH) 
device driver is the datalink used for the communication between the switch 
and the message desk. For 1X89 and FX30 MPC cards, the datalink consists 
of a 1200-baud, dedicated, full duplex line that transmits ASCH characters. It 
is an RS-232-C datalink which uses a device controller card. Neither 
end-to-end protocol nor integrity is provided. Retransmission of data that is 
incorrectly received is not supported. For CS 2000 - Compact, the ASCII 
messages are encapsulated in TCP/IP packets and sent to the IP address and 
port specified in fields REM_SMDR_IP_ADDR and PORT of table 
SLLNKDEV. 


As many as 64 datalinks are used to handle Simplified Message Desk Interface 
(SMDI) messages. Each datalink supports up to 999 desk numbers. 


Datafilling the datalink 


The entry for the datalink device (NT1X89, FX30 types) is in tables MPC and 
MPCLINK before the datafill in table SLELNKDEV. 


SMDI must have exclusive use of any datalink it uses in the multilink ASCII 
device driver. 


The following tables need to be datafilled for the datalink: 


Table 3-1 Required datafill for the datalink 


Table 


MPC * 
MPCLINK * 
SLLNKDEV 


* - For CS 2000 - Compact offices, tables MPC and MPCLINK do not need datafill. 
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What happens to messages during datalink failure? 


The switch (as instructed only by the input datalink messages from the TMS 
or VMS) activates or deactivates SMDI Message Waiting (MWT). Logs 
regarding the status of the datalink are generated for hardware or software 
failure. 


If the switch is unable to execute the message desk request, or the input 
datalink message contains invalid data, then the switch performs no action. 
The switch sends a negative acknowledgement message to the message desk. 
The message desk should recheck the data and try the transmission again. 


Message protocol 


The switch checks the messages received from the message desk for adherence 
to the following message protocols: 


Incoming messages—The switch accepts two kinds of incoming messages 
from the message desk: 


1. A message to activate the message waiting indicator (MWI): 


OP: MWI(SP)nnnnnnn! (D) 


2. A message to deactivate the message waiting indicator: 


RMV: MWI(SP)nnnnnnn! (D) 


Where: 

nnnnnnnnnn station number (seven or ten digits) 
(D) control-D (end of transmission) 
(SP) space 


For example, if the user with a directory number (DN) of 787-2000 has 
forwarded calls to the message desk and has received a message, the message 
desk activates the message waiting indicator for his station with the following: 


OP: MWI 7872000! (D) 
After the user has retrieved the messages from the message desk, the message 
desk deactivates the message waiting indicator for his station with the 


following: 


RMV: MWI 7872000! (D) 
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Outgoing messages—The switch sends two groups of messages to the 
message desk. 


1. 


Call detail messages provide details concerning calls being taken by the 
message desk, as shown in the following examples: 


(LF) (CR) (CR) (LF) MDaaabbbbinnnnnnn (SP) cccccce 
(SP) (CR) (LF) (Y) 
(LF) (CR) (CR) (LF)MDaaabbbbinnnnnnn (SP) (SP) (CR) (LF) (Y) 


(LF) (CR) (CR) (LF) MDaaabbbbi (SP) ccccccc (SP) (CR) (LF) (Y) 


MWI change failure messages indicate that the requests to change the 
message waiting indicator failed because it was invalid (INV) or because 
it was unable to perform the change when requested (BLK), as shown in 
the following examples: 


(LF) (CR) (CR) (LF) MWInnnnnnn (SP) INV (CR) (LF) (DL) (DL) (Y) 
(LF) (CR) (CR) (LF) MWInnnnnnn (SP) BLK(CR) (LF) (DL) (DL) (Y) 


(SP) space 

(CR) carriage return 

(LF) line feed 

(DL) delete character (ASCII value FF) 

(Y) control-Y 

aaa message desk number (001-063) 

bbbb message desk terminal or line number (0001-2047) 
ffffffft DN of hunt group 


nnnnnnnnnn forwarding from station number (can be seven or 
ten digits) 

eccccce calling station DN (can be seven or ten digits) 
i type of call 

direct calls 

forward all calls 

forward busy calls 

forward no answer calls 


Z2uPru 


For example, the user with a directory number of 787-2000 has all calls 
forwarded to the message desk. The caller with a DN of 361-1234 calls 
the user and is forwarded to message desk number 002, terminal 0009. 
The switch sends the following message to the message desk: 


(CR) (LF)MD0020009A7872000 3611234 (CR) (LF) (Y) 
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4 Changing datalink states 


Datalink states 


Depending on external conditions, (manual disconnection of the link, restarts, 
or hardware failures) and commands issued, the link can be in one of three 
states—connected, disconnected, or transferring. Only a link in the 
transferring state allows messages to pass across the link. Datalink states are 
checked with the LNKSTAT or SMDISTAT level commands. For a 

CS 2000 - Compact, if the link between the VMS and the CS LAN routers is 
not redundant, a switch of activity at the CS LAN will disconnect the link. 


For TCP datalinks, if the VMS machine has a dynamically configured IP 
address and the IP address changes after a reset, table SELNKDEV will not be 
automatically updated and the datalink will be disconnected. 


Command applicability 


For the 1X89 datalinks, the LNKSTAT , SMDISTAT, and QUIT commands 
are valid. 


The 1X89 and TCP datalinks are automatically connected and started when 
datafilled in table SLLNKDEV. The 1X89 datalinks are returned to service at 
the multi-protocol controller (MPC) MAP level. TCP datalinks are managed 
with the SMDILNK level commands. 


Command New state Description 


SMDISTAT connected Queries the status of Simplified Message 
Desk Interface (SMDI) input/output (I/O) 
and related datalinks. This command does 
not affect datalink status. 
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Command New state Description 


LNKSTAT connected Queries the status of SMDI I/O and related 
datalinks. This command does not affect 
datalink status. 


Note: LNKSTAT is available to only 1X89 
datalinks. 


QUIT connected Leaves the current command interpreter 
increment level. This command does not 
affect datalink or SMDI status. 


Command New state Description 


SMDISTAT transferring Queries the status of SMDI I/O 
communication on the links. This 
command does not affect SMDI or datalink 
status. 


LNKSTAT transferring Queries the status of data links and related 
SMDI I/O communication. This command 
does not affect datalink status. 


Note: LNKSTAT is available to only 1X89 
datalinks. 


QUIT transferring Leaves the current command interpreter 
level. This command does not affect 
datalink or SMDI status. 


Command interpreter commands 


SMDILNK command is a command interpreter (CI) command. The 
SMDISTAT level of the SMDILNK command allows the user to query SMDI 
TO information. 


For information on the LNKUTIL command LNKSTAT, see Commands 
Reference Manual. 


How to access SMDILNK command 
To access SMDILNK, perform the following steps on a MAP workstation at 


the CI level: 

System prompt User input 
El: 

> smdilnk 
SMDILNK: 
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SMDILNK commands 
In SMDILNK, the following commands are available to the user: 


SMDISTAT 

SMDICON - this command is only applicable to CS 2000 - Compact 
SMDIDISC - this command is only applicable to CS 2000 - Compact 
QUIT 


These commands are only available in SMDILNK CI increment and they 
require parameters that are related to SMDI I/O communication. 


SMDISTAT 
The SMDISTAT command gives information about SMDI I/O 
communication. 


Procedure 4-1 Determine SMDI link status 


At the MAP 


1 


Enter the SMDILNK level: 

> SMDILNK 

Enter the SMDISTAT command: 

> SMDISTAT link <link_name> 


link_name 
is the name of the SMDI link datafilled in field DEVNAME of table 
SLLNKDEV 


or use the ALL syntax: SMDISTAT ALL 
The status of the specified link or all SMDI links is reported: 


>SMDISTAT link smdi0 


LINK SMDIO 


SMDI I/O communication is routed on link SMDIO 
> 


Other responses: 


SMDI I/O COMMUNICATION IS ROUTED ON A POOL SECOND ON 
DEVICE SMDI5. 


SMDISTAT POOL SECOND was entered and a previous SMDICON 
command has been entered successfully. 


NO SMDI I/O COMMUNICATION HAS BEEN ROUTED ON POOL SECOND. 
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No SMDI I/O communication has been routed on pool SECOND. 


SMDI I/O COMMUNICATION IS POSSIBLE ON THE FOLLOWING POOLS 
AND THEIR ASSOCIATED DEVICES: 

POOL DEVICE SMDI I/O STATUS 

BOTTOM SMDI3 ROUTING 

TOP SMDI6 NOT ROUTING 

SECOND SMDI5 ROUTING 


SMDISTAT ALL was entered and two previous SMDICON commands have 
been entered successfully. TOP has either been started with LNKUTIL: 
DEVSTART but not connected with SMDILNK: SMDICON, or the link was 
connected with SMDILNK: SMDICON but not started with LNKUTIL: 


DEVSTART. 
3 This procedure is complete. 
SMDICON 


The SMDICON command is only available for CS 2000 - Compact offices 
with a TCP/IP datalink. This command is used to reestablish a datalink 
connection with the VMS. 


Procedure 4-2 Use SMDICON to connect TCP/IP datalink 


At the MAP 

1 Enter the SMDILNK level: 
> SMDILNK 

2 Enter the SMDICON command and indicate which SMDI link to connect: 
> SMDICON <pool> 


pool 
is the name of the SMDI link datafilled in field DEVNAME of table 
SLLNKDEV 


Log reports SLNK100 and SLNK102 are generated. The TCP/IP connection 
is reestablished: 


>SMDICON smdi0O 
Device SMDIO has been connected and started. 
> 


Note: Ifthe SMDI link was not provisioned in table SLLNKDEV, the 
following error message is printed: Device SDMI1 has not been 
datafilled in SLLNKDEV. No action taken. 


3 This procedure is complete. 


SMDIDISC 

The SMDIDISC command is only available for CS 2000 - Compact offices 
with a TCP/IP datalink. This command is used to disconnect a datalink 
connection to a VMS. 
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Procedure 4-3 Use SMDIDISC to disconnect a TCP/IP datalink 


At the MAP 


1 


Enter the SMDILNK level: 
> SMDILNK 


Enter the SMDIDISC command and identify which SMDI datalink to 
disconnect: 


> SMDIDISC <pool> 


pool 
is the name of the SMDI link datafilled in field DEVNAME of table 
SLLNKDEV 


Log reports SLNK103 and SLNK101 are generated. The datalink is 
disconnected: 


>SMDIDISC smdi0O 
Device SMDIO has been stopped and disconnected. 


> 


Note: Ifthe SMDI link was not provisioned in table SLLNKDEV, the 
following error message is printed: Device SDMI1 has not been 
datafilled in SLLNKDEV. No action taken. 


This procedure is complete. 
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5 Taking down and bringing up SMDI 
links 


Application of taking down and bringing up SMDI links 
Simplified Message Desk Interface (SMDIJ) links must be taken down before 
a device controller card can be changed or a software patch can be applied. The 
procedures in this chapter show how to take down and bring back up links after 
any alterations are made. SMDI links on a CS 2000 - Compact do not need to 
be taken down during patching. 


If a device controller card is being updated, this procedure should be used. If 
a card is going to be replaced with an identical card, this procedure is not 
necessary. 


Note: All work done while taking links down and bringing links up should 
be printed. This printout provides a detailed record of the steps used to alter 
the links. 


Taking down SMDI links 


The following flowchart is a summary of taking down SMDI links. Use the 
instructions that follow the flowchart to do this procedure. 
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Figure 5-1 Taking down SMDI links 


Log into a printer 


f 


Print tables UCDGRP, HUNTGRP, 
SLLNKDEV, and IBNFEAT 


j 


Take SMDI terminals off line * 


i 


Delete SMDI from lines 


i 


Remove SMDI from UCD groups 


í 


Remove SMDI from hunt groups 


í 


Delete tuples in table SLLNKDEV 


í 


Delete SMDI terminals * 


* - these steps are not needed 
for CS 2000 - Compact offices 


Printing table information 
Before beginning the take down procedure, information from tables UCDGRP, 


HUNTGRP, SLLNKDEV, TERMDEV, and IBNFEAT is needed. A printout of 
each table gives the needed information on SMDI groups, lines, and directory 
numbers. The following procedure shows how these printouts can be retrieved. 


System prompt User input 
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> record start onto <prtname> 
> quit all 
> table <table name>; lis all; quit 


The following table shows the command to print the needed tables from a 
MAP (maintenance and administration position). 


Note: The command to print table IBNFEAT is slightly different. 
Table 5-1 Printing table information 


>QUIT ALL 
>RECORD START ONTO PRTA 
>TABLE UCDGRP; LIS ALL; QUIT 


Note: The entire contents of table UCDGRP will be printed 


>TABLE HUNTGRP; LIS ALL; QUIT 


Note: The entire contents of table HUNTGRP will be printed. 


>TABLE SLLNKDEV; LIS ALL; QUIT 


Note: The entire contents of table SLLNKDEV will be printed. 


>TABLE TERMDEV; LIS ALL; QUIT 


Note: The entire contents of table TERMDEV will be printed. 


>TABLE IBNFEAT; LIS ALL (DF EQ SMDI); QUIT 


Note: All lines in table IBNFEAT with the SMDI option will be printed. 


Taking SMDI terminals offline 


Terminals must be taken offline. This is done at the input/output controller 
(LOC) level of the MAP station. This step does not need to be done for 
CS 2000 - Compact offices. 


The printout of table TERMDEY list all SMDI terminals. Use this printout to 
identify all terminals that need to be taken offline. 


Note: If all links are not going to be taken down, remove SMDI from only 
the agents whose links are being taken down. 


The following procedure shows how to get to the IOC level of the MAP and 
offline all SMDI terminals. Repeat this procedure for all SMDI terminals. 


Procedure 5-2 
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Getting to the IOC level of the MAP 


To get to the IOC level of the MAP, type in the following command: 


>MAPCI;MTC; IOD; IOC #> 


The following figure shows how a MAP station at the IOC level would look. 


Figure 5-2 IOC MAP display 


ee MS IOD Net PM CCS Lns Trks Ext aa 
IOC IOD 
0 QUIT IOC 0 1 2 
2 STAT . 
3 
4 ListDev_ DIRP : NO AMA XFER: A DPPP : . DPPU: . NOP: 2 ARG: 
5 NX25 : s MLP: z SLM: 
6 Tst_ 
7 Bsy_ IOC CARD (0) T 2 3 4 5 6 J 8 
8 RTS_ (0) PORT 0123 0123 0123 0123 0123 0123 0123 0123 0123 
9- -Off1_ STAT ERE aE Ghia St Sea GSES SSeS e E 
10 _IOC TYPE DDU MTD CONS CONS CONS MPC 
11 _Port_ 
12 
13 
14 Trnsl 
15 
16 
17 
18 Card_ 
08:15> 


i ye 


Select the SMDI card by entering the following: 


>CARD <CARD#> 


Busy the SMDI card by entering the following: 


>BSY <CKT#> 
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Offline the card by entering the following: 


>OFFL<CKT#> 


To return to the CI level of the MAP, enter the following: 


>QUIT ALL 


Deleting SMDI from lines 
After taking all SMDI terminals offline, the terminals can be deleted from all 
voice lines. Using the printout of table IBNFEAT, identify all directory 
numbers (DN) or line equipment numbers (LEN) of voice lines with SMDI. 
The Service Order system (SERVORD) command deletes SMDI from all 
lines. The following procedure shows how to delete SMDI through 
SERVORD. Repeat this procedure for all DNs or LENs. 


Procedure 5-3 


Deleting SMDI using SERVORD 


System prompt User input 
> deo 
SONUMBER: NOW 90 1 2 AM 
> (CR) 
DN_OR_LEN: 
> <frame><bay><drwr><card> 
OPTION: 
> smdi 
OPTION: 
> $ 
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The following table shows how deleting SMDI from lines using SERVORD 
would look at a MAP station. 


Table 5-2 Deleting SMDI using SERVORD 


Prompt mode 


>DEO (CR) SONUMBER: NOW 90 1 2 AM 
> (CR) 

DN_OR_LEN: 

>0 0 1 4 (CR) 

OPTION: 

>SMDI 

OPTION: 

>$ (CR) 

COMMAND AS ENTERED: 

DEO NOW 90 1 2 AM 0 O 1 4 SMDIS 

ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT 
>Y (CR) 


No-prompt mode 


> DEO $ 0 0 1 4 SMDI $ (CR) 


Removing SMDI from UCD groups 
SMDI must be deleted from all universal call distribution (UCD) groups. 
Using the printout of table UCDGRP, identify all UCD groups with SMDI. 
The following procedure shows how to delete SMDI from one UCD group. 
Repeat this procedure for all UCD groups with SMDI links that need to be 
taken down. 


Procedure 5-4 


Deleting SMDI from UCD groups 


System prompt User input 
> table ucdgrp 
TABLE UCDGRP: pos <ucd_name> 


> cha options 
OPTION: UCD_SMDI 
> $ 
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The following table shows how disabling SMDI messages would look at a 


MAP station. 
Table 5-3 Deleting SMDI from UCD groups 

>TABLE UCDGRP 

TABLE UCDGRP: 

>POS NDL3C 

UCDNAME ACD CUSTGRP UCDRNGTH THROUTE 

NSROUTE PRIOPRO MAXPOS DBG DEFPRIO RLSCNT MAXWAIT MAXCQSIZ 

OPTIONS 

NDL3C N 50B_CON 0 OFRT 30 

OFRT 30 0 16 N 1 0 0 16$ 

(UCD_SMDI SMDI1 4 (CLASSA) $)$ 

CHA OPTIONS 

OPTION: UCD_SMDI 

>$ 

TUPLE TO BE CHANGED: 

NDL3C N 50B_CON 0 OFRT 30 

OFRT 30 0 16 N 1 0 0 16 

ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT 

>Y 

TUPLE CHANGED 

>QUIT 

Note: This example shows a UCD group with only the SMDI option. If the UCD 
group has other options, do not delete them. 


Removing SMDI from hunt groups 
SMDI must be deleted from all hunt groups. Using the printout of table 


HUNTGRP, identify all UCD groups with SMDI. The following procedure 
shows how to delete SMDI from one hunt group. Repeat this procedure for all 
hunt groups linked to the SMDI links to be taken down. 

Procedure 5-5 

Deleting SMDI from hunt groups 


System prompt User input 
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> table huntgrp 
TABLE HUNTGRP: 

> pos<huntgrp> 
> cha grpdata 
CIR: 

> (CR) 

TFO: 

> (CR) 
TRMBOPT: 

> (CR) 
TRMBILL: 

> (CR) 

LOR: 

> (CR) 

LOD: 

> (CR) 

CFGDA: 

> (CR) 

OFR: 

> (CR) 

OFS: 

> (CR) 
E911PSAP: 

> (CR) 

SIZE: 1 

> (CR) 
OPTION: SMDI 

> $ 

TUPLE TO BE CHANGED: 


0 619 5206100 DNH N N N RCVD 
N N 
N 
N 1 $ 
ENTER Y TO CONFIRM, N TO REJECT OR 
>Y 
>QUIT 


E TO 


EDIT 


The following table shows how disabling SMDI messages would look at a 


MAP station. 


Table 5-4 Deleting SMDI from hunt groups 


>TABLE HUNTGRP 

TABLE HUNTGRP: 

>POS 0 

HTGRP SNPA DN GRPTYP 


other options, do not delete them. 


GRPDATA 


This example shows a hunt group with only the SMDI option. If the hunt group has 
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0 619 5206100 DNH N N N RCVD N 
N N 
N 
N 1 (SMDI 63 SMDI1)$ 
>CHA GRPDATA 
CIR: 
> (CR) 
TFO: N 
>(CR) TRMBOPT: N 
> (CR) 
TRMBILL: RCVD 
> (CR) 
LOR: N 
> (CR) 
LOD: 
> (CR) 
CFGDA:N 
> (CR) 
OFR: N 
> (CR) 
OFS: N 
> (CR) 
E911PSAP: N 


SIZE: 1 

> (CR) 

OPTION: SMDI 

>$ 

TUPLE TO BE CHANGED: 

0 619 5206100 DNH N N N RCVD N 
N N 


ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT 
>Y 
>QUIT 


This example shows a hunt group with only the SMDI option. If the hunt group has 
other options, do not delete them. 


Deleting tuples in table SLLNKDEV 
All tuples in table SLLNKDEV must be deleted. Use the printout of table 
SLLNKDEYV to locate all tuples. The following procedure shows the 
procedure for deleting one tuple from table SLLNKDEV. Repeat this 
procedure to delete only the tuples that correspond to the links you are taking 
down. 
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Deleting a tuple in table SLLNKDEV 


System prompt User input 

> table sllinkdev 
TABLE SLLNKDEV: 

> pos<devname> 
> del 


Table 5-5 shows how deleting one tuple in table SLLNKDEV would look at a 
MAP station. 


Table 5-5 Deleting a tuple in table SLLNKDEV 


>TABLE SLLNKDEV 
table SLLNKDEV: 
>pos smdil 


>DEL 

TUPLE TO BE DELETED: 

DEVNAME DEVIC XLATION PROTOCOL DRECTION 

XFERS 

SMDI1 1X67 NONE NONE INOUTLK 

ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT 

>Y 

TUPLE DELETED 

>QUIT 


Note 1: Repeat this procedure until no more tuples exist. Then enter the 
command QUIT. 


Note 2: |f you are not taking down all SMDI links, do not delete all tuples. You can 
position on a tuple by entering POS <devname>. Then delete by entering >DEL. 


Deleting SMDI terminals 
After the SMDI terminals are taken offline and deleted from voice lines, they 


can be deleted from table TERMDEV. Procedure 5-7 shows how to delete 
SMDI terminals. This procedure should be repeated for each SMDI terminal. 
This procedure is not needed for CS 2000 - Compact offices. 

Procedure 5-7 

Deleting all SMDI terminals from table TERMDEV 


System prompt User input 


297-2051-104 Preliminary 13.01 September 2004 


Taking down and bringing up SMDI links 5-11 


> table termdev 
TABLE TERMDEV: 
> pos<termdes> 
<TERMDES TUPLE>: 
> del 


Table 5-6 shows how deleting an SMDI terminal would look at a MAP station. 


Table 5-6 Deleting all SMDI terminals from table TERMDEV 


>TABLE TERMDEV TABLE TERMDEV: 
>POS SMDI1 
TERMDES IOCNO CKTNO TERMTYPE BAUDRT INTYP EQPEC PRTY GUAR 
MODEM COMCLASS 


SMDI1 0 8 SMDI B1200 EIA 1X67BC EVEN N NONE 


v 
UO 
lza] 
È 


TUPLE TO BE DELETED: 


SMDI1 0 8 SMDI B1200 EIA 1X67BC EVEN N NONE 
ALL 

ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT 

>Y 

>QUIT 


Bringing up SMDI links 
The following flowchart is a summary of bringing up SMDI links. Use the 
instructions that follow the flowchart to do this procedure. 
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Figure 5-3 Bringing up SMDI links 


Datafill table TERMDEV * 


y 


Add tuples to table SLLNKDEV 


t 


Add SMDI to UCD groups 


Y 


Add SMDI to hunt groups 


Y 


Add SMDI to lines 


j 


Return to service SMDI terminals * 


y 


Log out of a printer 


* - these steps are not needed 
for CS 2000 - Compact offices 


Datafilling table TERMDEV 
The first step in bringing up the SMDI links is to add SMDI terminals in table 
TERMDEV. It may be necessary to refer back to the printout for previous 
datafill information. Procedure 5-8 shows how the table TERMDEV would be 
datafilled to assign SMDI to terminals. This step is not needed for 
CS 2000 - Compact offices. 


Procedure 5-8 
Adding SMDI to table TERMDEV 


System prompt User input 
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> table termdev 

TABLE TERMDEV 

> add 

TERMDES 

> <device used in smdilnk> 

IOCNO: 

> <input/output controller number> 
CKTNO: 

> <input/output controller circuit number> 
TERMTYPE: 

> smdi 

BAUDRT: 

> b1200 

INTYP: 

> eia 

EQPEC 

> <PEC of terminal controller circuit pack> 
PRTY 

> even 

GUAR 

> n 

MODEM 

> none 

COMCLASS: 

> all 


Table 5-7 shows how adding SMDI to table TERMDEV would look at a MAP 
station. 
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Table 5-7 Adding SMDI to table TERMDEV 


>1X67BC 


ZVV 
A = 


HVAaY 
O 


L 
UPLE TO BE ADDED: 
SMDI1 O 8 SMDI B1200 EIA 1X67BC EVEN N NONE 


ALL 


ENTER Y TO CONFRIM, N TO REJECT OR E TO EDIT 


TUPLE ADDED 
>QUIT 


Note 1: Field <EQPEC>should be datafilled with the card PEC code. Field 
<TERMTYPEsshould be datafilled with SMDI. All other fields should be datafilled 
as shown on the printout of table TERMDEV. 


Note 2: After the addition of one tuple, two tuples actually appear. The second 
tuple is identical except for field <TERMDESs-. It cannot be changed or deleted. All 
changes or deletions must be made to the first tuple. 


Datafilling table SLLNKDEV 
After busying all terminals, all tuples that were deleted can be added back to 
table SLLNKDEV. Use the printout of table SELNKDEV to identify the 
contents of each tuple. Procedure 5-9 shows how to add a tuple to table 
SLLNKDEV. Repeat this procedure until all original tuples are added. 
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Adding tuples to table SLLNKDEV 


System prompt User prompt 
> table sllinkdev 
TABLE SLLNKDEV: 

> add 

DEVNAME : 

> <devname> 
DEVICE: 

> <devtype>(1X67, 1X89, FX30, TCP) 
XLATION: 

> none 
PROTOCOL: 

> none 
DRECTION: 

> inoutlk 

XFER: 

> smdidata 
OPTION: 

> numofdigs 
NUMDIGS 

<7,10,or var> 

OPTION: 

> dnsuppr 
CALLING: 

> indirect 
FWDING: 

> conditnl 
OPTION: 

> $ 

XFER: 


$ 
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Table 5-8 shows how adding tuples to table SLLNKDEV would look at a MAP 
station. 


Table 5-8 Adding tuples to table SLLNKDEV 


>TABLE SLLNKDEV 
TABLE SLLNKDEV: 
>ADD 


SMDT1 
EVICE: 
1X67 
LATION: 


2 
O 
Zz 
ira) 


ROTOCOL: 
NONE 
DRECTION: 
>INOUTLK 
XFER: 
>SMDIDATA 
OPTION: 
>NUMOFDIGS 
NUMDIGS: 
>7 
OPTION: 

>DNSUPPR 

CALLING: 

>INDIRECT 

FWDING: 

>CONDITNL 

OPTION: 

$ 

XFER 

$ 

TUPLE TO BE ADDED: 

DEVNAME DEVICE XLATION PROTOCOL DRECTION 


MEV A VO vyv 


SMDI1 1X67 NONE NONE INOUTLK 
(SMDIDATA (NUMOFDIGS 7) (DNSUPPR INDIRECT CONDITINL $)$ 
ENTER Y TO CONFIRM N TO REJECT OR E TO EDIT 

>Y 

TUPLE ADDED 

>QUIT 


Adding SMDI to UCD groups 
SMDI must be reassigned to UCD groups. Using the printouts of table 
UCDGRP identify all DNs or LENs of UCD groups that had SMDI. Procedure 
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5-10 shows how to delete SMDI from all UCD groups. Repeat this procedure 
for all UCD groups requiring SMDI. 


Procedure 5-10 


Adding SMDI to UCD groups 


System prompt User input 
> table ucdgrp 
TABLE UCDGRP: pos <ucd_name> 
> cha options 
OPTION: AUDIO 
> ucd_smdi 
SMDI_LINK: 
> <dev_name> 


SMDI_DESK_NO: 


<value of 1 to 999> 


MCOS_LIST: 

classa 
MCOS_LIST: 
> $ 
OPTION: 
> $ 


DMS-100 Family MDC SMDI Setup and Operation SN04 and up 


5-18 Taking down and bringing up SMDI links 


Table 5-9 shows how adding SMDI to UCD groups would look at a MAP 
station. 


Table 5-9 Adding SMDI to UCD groups 


>TABLE UCDGRP 
TABLE UDCGRP: 


>POS 

UCDNAME ACD CUSTGRP UCDRNGTH THROUTE 

NSROUTE PRIOPRO MAXPOS DBG DEFPRIO RLSCNT MAXWAIT MAXCQSIZ 

OPTIONS 

NDL3C N 50B_CON 0 OFRT 30 

OFRT 30 0 16 N 1 0 0 16$ 

CHA OPTIONS 

OPTION: AUDIO 

>UCD_SMDI 

SMDI_LINK: 

>SMDI1 

SMDI_DESK_NO: 

>4 

MCOS_LIST: 

>CLASSA 

MCOS_LIST: 

>$ 

OPTION: 

>$ 

TUPLE TO BE CHANGED: 

NDL3C N 50B_CON 0 OFRT 30 

OFRT 30 0 16 N 1 0 0 16 
(UCD_SMDI SMDI1 4 (CLASSA) $)$ 

ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT 

>Y. 

TUPLE CHANGED 

>QUIT 


Note: Verify that all tuples match originals from printout. 


Adding SMDI to hunt groups 
SMDI must be reassigned to hunt groups. Using the printouts of table 
HUNTGRP, identify all DNs or LENs of hunt groups that had SMDI. 
Procedure 5-11 shows how to delete SMDI from all hunt groups. Repeat this 
procedure for all hunt groups requiring SMDI. 


Procedure 5-11 
Adding SMDI to hunt groups 


System prompt User input 
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table huntgrp 
TABLE HUNTGRP: 


> pos <huntgroup> 
> cha grpdata 
CIR: 
Z (CR) 
TFO: 
> (CR) 
TRMBOPT: 
> (CR) 
TRMBILL: 
> (CR) 
LOR: 
> (CR) 
LOD: 
> (CR) 
CFGDA: 
> (CR) 
OFR: 
> (CR) 
OFS: 
> (CR) 
E911PSAP: 
> (CR) 
SIZE: 
> (CR) 
OPTION: 
> smdi 
SMDIDESK: 

63 
SMDILINK: 

smdil 
OPTION: 

$ 
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Table 5-10 shows how adding SMDI to hunt groups would look at a MAP 


station. 


Table 5-10 Adding SMDI to hunt groups 


>TABLE HUNTGRP 

TABLE HUNTGRP: 

>POS 4 

HTGRP SNPA DN GRPTYP 


N 


>CHA GRPDATA 
CIR: N 

> (CR) 

TFO: N 

> (CR) 

TRMBOPT: N 

> (CR) 

TRMBILL: RCVD 
> (CR) 

LOR: N 

> (CR) 

LOD: N 

> (CR) 

CFGDA:N 

> (CR) 

OFR: N 

> (CR) 

OFS: N 

> (CR) 

E911PSAP: N 

> (CR) 

SIZE: 1 

> (CR) 

OPTION: 

>SMDI 
SMDIDESK: 
>63 
SMDILINK: 
>SMDT1 
OPTION: 


M 4 619 5206100 DNH N N N 


GRPDATA 
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Table 5-10 Adding SMDI to hunt groups 


>$ 
TUPLE TO BE CHANGED: 
0 619 5206100 DNH N N N RCVD N 
N N 
N 
N 1 (SMDI 63 SMDI1)$ 
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT 
>Y 
TUPLE CHANGED 
>QUIT 


Adding SMDI to lines 
SMDI must be reassigned to all lines. Using the printout of table IBNFEAT, 
identify all DNs or LENs of voice lines that had SMDI. The SERVORD 
command is used to reassign SMDI to all lines. Table 5-12 shows the 
procedure for adding SMDI to a line by SERVORD. Repeat this procedure for 
all DNs or LENs. 


Procedure 5-12 


Adding SMDI using SERVORD 


System prompt User input 
> ado 
SONUMBER: NOW 90 1 2 AM 
> (CR) 
DN_OR_LEN 
> <frame><bay><drwr><card> 
OPTKEY: 
4 
OPTION 
> smdi 
LINENO: 
5 
UCDGRP: 
<ucdgrp_number> 
AUTO_LOG 
Yy 
OPTKEY 
> $ 


The following table shows how adding SMDI to lines using SERVORD would 
look at a MAP station. 
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Table 5-11 Adding SMDI using SERVORD 
Prompt mode 


>ADO (CR) SONUMBER: NOW 90 1 2 AM 
> (CR) 

DN_OR_LEN: 

> 001 4 (CR) 

OPTKEY: 

>4 

OPTION: 

>SMDI 

LINENO: 


>$ (CR) 
COMMAND AS ENTERED: 

ADO NOW 90 1 2 AM HOST 0 O 1 4 (4 SMDI 5 _NUMBER> Y)$ 
ENTER Y TO CONFIRM,N TO REJECT OR E TO EDIT 

>Y (CR) 


No-prompt mode 


>ADO $ HOST 0 0 1 4 4 SMDI 5 _NUMBER> Y $ 


Returning SMDI terminals to service 


Before the tuples that have been deleted from table SLLNKDEV can be added, 
SMDI terminals must be RTS (returned to service). See table TERMDEV for 
a list of all SMDI terminals. This is procedure is not needed for 

CS 2000 - Compact offices. 


Procedure 5-13 shows how to get to the IOC level of the MAP and RTS all 
SMDI terminals. 


Procedure 5-13 
Getting to the IOC level of the MAP 


To get to the IOC level of the MAP, type in the following command: 


>MAPCI;MTC;IOD;IOC #> 
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Figure 5-4 shows how a MAP at the IOC level would look. 


Figure 5-4 IOC MAP display 


a MS IOD Net PM CCS Lns Trks Ext oa 
IOC IOD 
0 QUIT Toc 0 1 2 
2 STAT . 
3 
4 ListDev_ DIRP : NO AMA XFER: š DPPP : DPPU: . NOP: 2 ARG: 
5 NX25 : s MLP: : SLM: 
6 Tst_ 
7 Bsy_ IOC CARD (0) 1 2 3 4 5 6 7 8 
8 RTS_ 0 PORT 0123 0123 0123 0123 0123 0123 0123 0123 0123 
9 Offl_ STAT Besa SSS" Lda. ates SSS ee SS SSS SSS SS == 
10 _IOC TYPE DDU MTD CONS CONS CONS MPC 
11 _Port_ 
12 
13 
14 Trnsl 
15 
16 
17 
18 Card_ 


% 08:15> P 


Select the SMDI card by entering the following: 


>CARD <CKT #> 


Busy the SMDI card by entering the following: 


> BSY <CKT #> 


Return the card to service by entering the following: 


> RTS <CKT #> 


To return to the CI level of the MAP, enter the following: 


> QUIT ALL 


DMS-100 Family MDC SMDI Setup and Operation SN04 and up 


6-1 


6 Log reports for SMDI 


Logs 


Logs provide a history of activities on each datalink. Logs record information 
regarding the following: 


start or stop of data transfer 


database initialization of the downstream processor (DSP) 


start or stop of call event message generation 


error conditions 


The following logs contain information that applies to the Simplified Message 
Desk Interface (SMDIJ) input/output (I/O) communication: 


SLNK100 
SLNK101 
SLNK102 
SLNK103 
SLNK104 
SLNK105 
SLNK106 
SLNK107 
SLNK108 
AMAB150 
SMDI100 
SMDI101 
SMDI102 
SMDI103 
SMDI104 
SMDI105 
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e SMDI106 
e SMDI107 
e SMDI108 
e PRA200 

e NMS100 
e NMSI1OI1 
e NMS102 
e NMS103 
e NMS104 


This section gives examples of possible log reports. For more information on 
logs, or information on multi-protocol controller (MPC) log reports, see the 
Log Report Reference Manual. 


SLNK100 
The SMDI Link (SLNK) subsystem generates log report SLNK100 for each 
datalink device when the device connects with the use of the DEVCON 
command in LNKUTI or SMDICON in the SMDILNK level. 


Figure 6-1 Example of report format for SLNK100 


SLNK100 FEB12 01: 45: 56 1181 INFO SESSION 
Session connected on device S134 


SLNK101 
The SLNK subsystem generates log report SLNK101 for each datalink device 
when the device disconnects with the use of the DEVDISC command in 
LNKUTIL level or SMDIDISC in the SMDILNK level. 


Figure 6-2 Example of report format for SLNK101 


SLNK101 FEB12 02: 45: 56 1181 INFO SESSION 
Session disconnected on device $134 
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SLNK102 
The SLNK subsystem generates log report SLUNK102 for each datalink device 
when the system starts data transfer with the DEVSTART command in the 
LNKUTIL for the CI increment. 


Figure 6-3 Example of report format of SLNK102 


SLNK102 FEB12 03: 45: 56 1181 INFO SESSION 
SMDR Reports transfer started on device MRLINK 


SLNK103 


The SLNK subsystem generates log report SLNK103 for each datalink device 
when the system stops data transfer with the DEVSTOP command in the 
LNKUTIL for the CI increment. The SLNK103 log is a critical log so the 
display includes three asterisk. 


Figure 6-4 Example of report format of SLNK103 


***SLNK103 FEBI2 04: 45:56 2000 INFO SESSION 
SMDR Reports transfer stopped on device MRLINK 


SLNK104 
The SLNK subsystem generates log report SLUNK104 when the system starts 
down stream processor initialization on a pool with the INIT command in the 
ACDMR CT interface. The SLNK104 log is a critical log so the display 
includes three asterisk. 


Figure 6-5 Example of report format of SLNK104 


***SUNK104 FEB12 04: 45:56 2000 INFO MGTRPT 


ACD Management Reports initialization started on 
pool MRPOOL 


SLNK105 
The SLNK subsystem generates SLNK105 log report when the system 
completes down stream processor initialization on a pool. 
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Figure 6-6 Example of report format of SLNK105 


SLNK105 FEB14 01: 45: 56 2000 INFO MGTRPT 


ACD Management Reports initialization completed on 
pool MRPOOL 
Number of groups: 92 Number of positions: 857 


SLNK106 
The SLNK subsystem generates log report SLNK106 when the system does 
not queue a remote operation (RO) in the last 2 minutes. The system queues an 
RO for a data link device. The failure occurs because of a full queue. As a 
result, the system discards new messages or overwrites old messages. 


Figure 6-7 Example of report format of SLNK106 


SLNK106 FEB15 01: 45: 56 2000 INFO SESSION 


Last occurrence = 2000/02/15 01:43:20.940 SAT 
Total number of overflow msgs = 46 


To reduce the message volume on the data links perform one of the following 
actions: 


e assign additional devices to the pool to provide load-sharing 


e reroute some of the message traffic assigned to the pool that overflows 


SLNK107 
The SLNK subsystem generates log report SLNK107. This report appears if 
the DMS-100 link wakeup (SLLNKWKP) does not restart a 1X67 datalink 
after a restart or link failure. 


Manual intervention requires the following actions: 


e determine if the datalink is in service. If the data link is not in service, 
return the link to service. 


e determine if the link is in the connected state. If the link is not in a 
connected state, return the link to a connected state 


e determine if the system starts the appropriate transfer types on the link. If 
the system did not start the appropriate transfer types on the link, start the 
transfer types. 
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Figure 6-8 Example of report format of SLNK107 


SLNK107 JUN12 01: 45: 56 1181 INFO_LINK_WAKEUP_FATLURE 
Device SMDI5 has failed to restart. 
It requires manual intervention. 


SLNK108 
The SLNK subsystem generates log report SLNK108 when the SMDI 
incoming or outgoing process stops. The processes that follow refer to SMDI: 


e SMDIOG is the outgoing process for the 1x67 device. 

e SMDINC is the incoming process for the 1x67 device. 

e SMDINMPC is the incoming process for the 1x89 and Fx30 devices. 

e SLMPCOGT is the outgoing process for the 1x89 and Fx30 devices. 

e SLLNKOGT is the outgoing process for the SMDI link. 

e SLLNKICT is the incoming process for the SMDI link. 

Each process is for each link except the SMDINMPC process. There is one 


process for the switch. The SMDI103 log generates when the SMDINMPC 
process stops instead of the SLNK108 log. 
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The SMDI process stops because of hardware or software problems. The 
SLNK108 log generates when the SMDI process stops because of the software 
problems that follow: 


file status is not acceptable for the 1x67 device 


did not take resource for the 1x67, 1x89, Fx30, and the SLLNKOGT 
(SL-100) 


did not allocate pool for the 1x67 


did not allocate resource for the 1x67, 1x89, Fx30, and SLLNKOGT 
(SL-100) 


did not get the resource for the 1x67, SELNKOGT, SLLNKICT (SL-100) 
Nil SMDI descriptor for the 1x67 

did not setup the files for the 1x67 

incorrect message in the mailbox for the 1x67 

the mailbox is not acceptable for the 1x67, 1x89, and Fx30 

no entry in the datafill for the SLLNK device for SMDI for the 1x67 

no allocation for the SMDI pool for the 1x67 

did not allocate the mailbox for the 1x67 

the SMDIOG process is not acceptable for the 1x67 

the SMDI link is not available for the data transfer for the 1x89 or Fx30 
did not receive the SLMPC wakeup message for the 1x89 or Fx30 


The SLNK108 log generates when the SMDI process stops because of the 
hardware problems that follow: 


input output controller (IOC) port is in service for the 1x67 

driver is not up for the 1x67 

port is not up for the 1x67 

deletion of the link for the 1x67 

the SLLNK device did not initialize for the 1x89 or Fx30 

the SMDI device is not part of the SLLNK pool for the 1x89 or Fx30 
did not release the resource for the 1x89 or Fx30 

did not send data out on the SELNKOGT link for the SL-100 


The switch generates the SLNK108 log as a MAJOR or CRITICAL log. If the 
SMDI process stops because of software problems the SLNK108 log is a 

major log. Two asterisk at the beginning of the report indicate a major log. If 
the SMDI process stops because of hardware problems the SLNK108 log is a 
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CRITICAL log and three asterisk appear at the beginning of the log report. The 
examples for the log report SLNK108 follows. 


Figure 6-9 Examples of report format of SLNK108 


**x*XSULNK108 FEB15 18:14:33 4827 SMDI_DEAD_ PROCESS REPORT 
Port is not up. SMDIINC process killed. 
DATALINK = SMDIO 


***SULNK108 FEB 15 18:15:33 4828 SMDI_DEAD_ PROCESS REPORT 
Incorrect message in mailbox. SMDIOG process killed. 
DATALINK = SMDIO 


The SMDIERROR alarm for software problems and the SLNKERR alarm for 
hardware problems generate with the SLNK108 log. 


For more information on the SLNK108 log software or hardware problems, 
descriptions, or actions, see the Log Report Reference Manual. 


AMAB150 


The number 10 in the TERM_FC field of AMAB150 indicates the type of call 
as a call request retrieval and is enclosed in quotes in the example to 
demonstrate the position of the TERM_FC field. 


Figure 6-10 Example of report format of AMBA150 


AMAB150 JULO3 15:25:29 6707 INFO SMDR_CALL_DATA 


Q 


USTGRP = CUSGRP1 

0 0 6137227111 ** 00 0 6137227112 ** + 
"10" 0 25112***x*xxxxRKKKX COZ 12 30 02 000006 
ORIG = LEN HOST 00 1 02 13 DN 7227111 + 

TERM LEN HOST 00 1 05 13 DN 7227112 + 

ANS=Y 0 
DTO = ******* AUTH = ***** ACC Hk*KKKKK 


jo) 


Note: The plus sign (+) indicates that the next line is a continuation of the 
text. In the actual log report, all the information appears on the same line. 
Due to space limitations here, the text lines are split. 
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SMDI100 
SMDI100 log generates when the switch finds an error in the SMDI message 
waiting indicator (MWI). The error report text indicates the reason for the 
error. 


Figure 6-11 Example of report of SMDI100 


SMDI100 NOVO8 15: 26: 53 3122 INFO SMDI_ERR_REPORT 
REQUESTEE STATION MISSING MWT OPTION 

UCD GROUP INFO = IBNUCDGRP1 DATALINK = SMDILKO 
REQUESTEE INFO = $ LEN HOST 2 0 0 13 DN 7227640 


If the SMDI call retrieval billing option is active in the switch, an AMAB150 
log report with a title SMDR_CALL_DATA generates for each SMDI call 
retrieval. This information is also on the SMDR tape. The SMDI call retrieval 
billing option also provides additional information within the AMAB150 
report to determine a call retrieval using the call request feature from a direct 
call. 


If the SMDR option is disabled, then SMDR reports are not generated. For 
more information on SMDR, refer to the Meridian Digital Centrex Station 
Message Detail Recording Reference Guide, 297-2071-119. 


SMDI101 
This report generates for each datalink the first time a call to a voice messaging 
system (VMS) voice link and the SMDI cannot send the SMDI message. 


Figure 6-12 Example of report format of SMDI101 


SMDI101 NOVO8 15: 26: 53 3122 INFO SMDI_ERR_REPORT 
DATALINK IS DOWN. FAILED TO SEND SMDI MESSAGE. 
DATALINK = VMSLINK1 


SMDI102 


This report generates for each datalink the first time an SMDI message could 
be successfully enqueued after an SMDI101 log was previously generated. 
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Figure 6-13 Example of report format of SMDI102 


SMDI102 NOVO8 15: 26: 53 3122 INFO SMDI_ERR_REPORT 
DATALINK IS UP. DATALINK = VMSLINK1 


SMDI103 
The SMDI103 log generates when the SMDINMPC (simplified message desk 
interface network multiprotocol controller) process stops. The SMDINMPC 
process is the incoming process for the 1x89 and Fx30 devices. There is one 
SMDINMPC process for the switch. The two asterisks in the SMDI103 log 
show that the log is a major log. The SMDIERROR (simplified message desk 
interface error) alarm generates with the SMDI103 log. 


Figure 6-14 Example of report format of SMDI103 


**SMDI103 FEB24 15:28:59 7500 INFO SMDI INCOMING PROCESS 
SMDINMPC process died Require manual intervention 


SMDI104 


This report generates to indicate that the switch does not locate a primary desk 
for a host requesters line. The switch uses a rotational message desk for the 
host requesters line. 


Figure 6-15 Example of report format of SMDI104 


SMDI104 NOVO8 15:26:53 3122 INFO SMDI_DESK_ERR_ REPORT 
Rotational Desk used. NO primary desk for DN. 

UCD GROUP INFORM = VM1GRP DATALINK = VMAIL1 
REQUESTEE INFO = $ LEN HOST 2 0 013 DN 7224444 


SMDI105 
This report generates to indicate that the switch fails does not locate a common 
message desk for a network message waiting indicator (MWI) request (setting 
or removal). The first message desk datafilled is used to set MWI. 


Figure 6-16 Example of report format of SMDI105 


SMDI105 NOVO8 15:26:53 3122 INFO SMDI_NETWORK_ERR_REPORT 
Failed to determine a Common Desk for Network MWI 

Request. 
UCD GROUP INFORM = VM1GRP DATALINK = VMATLI1 
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SMDI106 


This report generates to indicate that the switch does not locate the message 
desk number that relates to the option COMMON of table SELNKDEV. 


Figure 6-17 Example of report format of SMDI106 


SMDI102 NOVO8 15:26:53 3122 INFO SMDI_COMMON_ERR_ REPORT 
DESKNUM message desk of COMMON option does not exist. 
UCD GROUP INFO = VM1GRP DATALINK = VMAIL1 


SMDI107 


The SMDI107 log generates when the files of a 1x67 card does not allow the 
write option for outgoing messages and the read option for incoming 
messages. 


Figure 6-18 Example of report format of SMDI107 


SMDI107 NOVO8 15: 26: 53 3122 INFO_SMDI_FILE_STATUS 
FILE STATUS NOT O.K. 
DATALINK_INDEX = VMAIL1 


SMDI108 
The SMDI108 log generates when the IOC (input output controller) port is not 
in service. The three asterisks appear in the SMDI108 log to indicate the 


critical status. The SLLNKERR alarm for hardware problems generates with 
the SMDI108 log. 


Figure 6-19 Example of report format of SMDI108 


***SMDI108 FEB15 09:21:59 4827 INFO_SMDI_HW_AUDIT 
IOC PORT NOT IN SERVICE FOR LINK. 
DATALINK_INDEX = VMAIL1 


PRA200 
This report generates at the host node if a Network Message- Waiting 
Indication (MWI) request specifies an invalid DN and there is no entry for a 
route in table MSGRTE. 
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Figure 6-20 Example of report format of PRA200 


PRA200 NOVO8 15:26:53 3122 INFO TCAP FAC SEND FAILED 
ORG NETID: 0 DN: 6137221121 


DST NETID: 0 DN: 6137221123 
PKG TYPE: QUERY_W_PERMISSION 

REASON: NO ROUTE DATAFILLED 
32E2 04C7 0000 0008 2AE8 28E9 O1CF D101 
7EO2 F203 AAIF 841D 0109 2100 160A 2273 
3211 CODF 0949 OOFA OA21 7316 1122 DF12 
45C0 0101 OO7F EBAD CE12 210A 000A 001D 


NMS100 
The NMS100 log report generates at a host when a message service generates 
an address that is not valid. The NMS 100 log generates if the network message 
service (NMS) subsystem is present. The NMS100 log relates to the OM 
register NMSINVAD of OM group NMS. The NMS100 log provides 
information only. 


Figure 6-21 Example of report format of NMS100 


NMS100 FEB28 08:12:57 1234 INFO INVALID ADDRESS FROM NMS 
INVALID ADDR = 9999999999 


NMS101 
The NMS101 log generates at the server node. The log appears when there is 
a message wait indicator change request for a vacant subscriber directory 
number (DN). The NMS101 log generates if the NMS subsystem is present. 
The NMS101 LOG relates to the OM register NUS VACT of OM group NMS. 
The NMS101 log provides information only. 


Figure 6-22 Example of report format of NMS101 


NMS101 FEB28 09:12:57 1235 INFO VACANT NMS SUBSCRIBER DN 
INVALID ADDR = 8153692666 


NMS102 


The NSM102 log generates at the server node when there is no notification to 
the subscriber DN for a short term reason. An example of a short term reason 
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is that the line is temporarily out of service. The NMS102 log detects problems 
that cause a network message service to send incorrect DNs. The network 
message services are empty subscriber DNs, global title translation is not 
functioning correctly, or the message service is generating invalid DNs. Refer 
to the DNINV table for the correct datafill. 


Figure 6-23 Example of report format for NMS102 


NMS102 FEB28 09:12:59 1236 INFO NOTIFICATION UNAVAILABLE 
SUBSCRIBER DN = 6135252666 


NMS103 


The NMS103 log report appears at the server node when a transaction 
capabilities application part (TCAP) response receives a component return 
error. The NMS103 log detects problems that cause a network message service 
to send incorrect DNs. The network messages services are empty subscriber 
DNs, global title translation is not functioning correctly, or the message service 
is generating incorrect DNs. Refer to the DN table for the correct datafill. The 
NMS 103 log relates to NMS group OM registers: NMSVACT and 
NMSINVAD. 


Figure 6-24 Example of report format for NMS103 


NMS103 FEB29 09:12:59 1237 INFO NOTIFICATION UNAVAILABLE 
TO DESTINATION DN 
SUBSCRIBER DN = 6135252681 


NMS104 
The NMS104 log generates when the transaction identifier (TRID) cannot 
release by the identifier pool (IDPL) functionality after sending a transaction 
capabilities application part (TCAP) message. The NMS104 log generates 
when the NMS subsystem is present. The IDPL functionality dynamically 
creates the TRID. 


Figure 6-25 Example of report format for NMS104 


NMS104 FEB28 10:12:59 1235 INFO TRID_UNRELEASE_ REPORT 
TRANSACTION ID cannot release. 
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7 Using the Service Order system 


For the CS 2000 - Compact, customers may elect to use OSSgate for line 
option provisioning instead of the Service Order system (SERVORD). 


Service Order system 
SERVORD is used to add, change, or delete features. SERVORD goes through 


the table editor to fill the customer tables as if entries were made directly into 
the tables. 


To open a service order, log on to the MAP (maintenance and administration 
position) and enter SERVORD. For instructions on how to log on to the MAP 
station and begin a service order, and an explanation of service order 
commands, see the SERVORD Reference Manual. 


SMDI can be added to a uniform call distribution (UCD) line using the ADO 
command. This allows the line to be included in a Simplified Message Desk 
Interface (SMDI) UCD group and enables that UCD line to be a part of the 
message desk. 


Always add the UCD option in table IBNLINES through SERVORD. The 
following examples show how the UCD and SMDI options are added through 
SERVORD. The UCD option must be assigned before adding the SMDI 


option. 
System prompt User input 
> servord 
SO: 
> ado 


SO_NUMBER: NOW 92 12 12 
> (CR) 
DN_OR_LEN: 
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System prompt User input 
> 7224111 
OPTKEY: 

> 5 

OPTION: 

> UCD 
OPTKEY: 

> $ 

SO: 

> ado 


SO_NUMBER: NOW 92 12 13 


> (CR) 
DN_OR_LEN: 

> 7224111 
OPTION: 

> smdi 
LINENO: 

> 25 
UCDGRP: 

> messdesk 
AUTOLOG: 

> y 


The SMDI option can be removed from a UCD line through the DEO 
command. 


297-2051-104 Preliminary 13.01 September 2004 


8-1 


8 Operational measurements 


SMDI OM groups 


Operational measurements (OM) control the collection and display of 
operating data associated with the switch. Refer to the Operational 
Measurements Reference Manual, for more detailed information. 


For information on multi-protocol controller (MPC) OMs see the Translations 
Guide. 


Simplified Message Desk Interface (SMDI) uses the following two OM 
groups: 
e SLLNK 
— SLLNKOVF 
— SLLNKOK 
— SLLNKQU 
e SLLNKINC 
— SLLNKIOV 
— SLLNKIOK 
— SLLNKIOF 
— SLLNKIQU 
— SLLNKBAD 
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SLLNK 
The SLLNK provides the measurements for the outgoing datalink utilities 
pertaining to SMDI data communication. The following tables list information 
about the measurements. 


Table 8-1 SLLNK measurements 


SLLNKOVF 


SLLNKOK 


SLLNKQU 


This is the number of messages that are overwritten or thrown away in an 
attempt to enter a full queue. A full queue is one that has no more available 
queue item buffers for queuing messages. It is incremented every time a valid 
message fails to enter because of a full queue and, as a result, is thrown away 
or overwrites a previous message. SLLNKOVF is expected to be very low, if not 
0. The chance of message overflow increases as register SLLNKQU increases. 
It should not exceed the maximum value of the OM register. Log SLNK106 is 
also generated when a queue overflow occurs. 


This is the number of messages successfully queued for transfer to the down 
stream processor. It is incremented every time a valid message is successfully 
queued for transfer to the down stream processor. 


This records the number of messages in the queue waiting to be processed 
(queue usage). Averaging is done by dividing this number by the number of 
times slow samples were taken. 


SLLNKINC 


SLLNKINC provides the following measurements for the incoming datalink 
utilities pertaining to SMDI data communication. 


Table 8-2 SLLNKINC measurements 


SLLNKIOV 


SLLNKIOK 


SLLNKIOF 


This is the number of messages that are overwritten or thrown away in an 
attempt to enter the queue on a full incoming queue. A full queue is one which 
has no available free queue item buffers with which to queue a message. It is 
incremented every time a valid message fails to enter the queue due to a full 
queue and, as a result, the message is discarded or overwrites a previous 
message. SLLNKIOV is expected to be very low, if not 0. The chance of 
message overflow increases as register SLLNKIQU increases. It should not 
exceed the maximum value of the OM register. Log SLNK106 is also generated 
when a queue overflow occurs. The log alerts the user to this failure so that a 
reference to OM can be made for details. 


This is the number of messages queued successfully that will be received from 
the datalink. This OM is incremented every time a valid message is queued 
successfully and will be received from the datalink. 


This is the overflow register for SLLNKIOK. This OM is incremented every time 
a valid message is queued successfully and received from the datalink, and 
SLLNKIOK has overflowed. 
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Table 8-2 SLLNKINC measurements 


SLLNKIQU This records the number of messages in the queue waiting to be processed 
(queue usage). Averaging is done by dividing this number by the number of 
times slow samples were taken. This OM usage register is incremented every 
100 seconds. 


SLLNKBAD This is the number of messages in an invalid format that are received from the 
datalink. It is incremented every time an invalid message is removed from the 
queue by the incoming processing task. 
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9 SMDI:features 


Simplified Message Desk Interface (SMDI) features apply to the SMDI 
package. Table 9-1 lists features associated with the SMDI feature package. 


Table 9-1 SMDI features 


Feature name Number Package Release 
Message Service - Network Message Waiting AG1638 NTXA68AA BCS30 
Indicator and 

NTX797AA 
RES SMDI CLID Suppression AG1980 NTXNO7AA BCS31 
SMDI: Called DN Option and KSH Support NC0009 NTX732AA BCS31 
Message Waiting Indicator - PRI AJ1538 NTX797AA BCS33 
Flexible Line Delivery on SMDI AF6300 NTXNO7AB DMSCCM06 
RES High Speed SMDI AF5725 NTX732AA DMSCCM04 

and 

NTXN10AA 
Remote Call Forwarding Enhancements AQ1245 RES00020 NAOO1 
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AG1638 - Message Service—Network MWI 


Name 
Message Service—Network Message Waiting Indicator 
Number 
AG1638 
Package 
NTXA68AA and NTX797AA 
BCS 


BCS33 and up 


Feature package prerequisites 


The Message Service—Network Message Waiting Indicator feature in feature 
package NTXA68AA requires the following feature packages: 


Feature package prerequisites 

Feature package Feature package name 

NTXOO0AA Bilge 

NTX001AA Common Basic 

NTX100AA Integrated Business Networks - Basic (IBN) 
NTX101AA IBN - Enhanced Business Services 
NTX119AA IBN - Message Service 

NTX167AB CCS7 - Trunk Signalling 

NTX550AA CCS7 - Transaction Service Support 
NTX901AA Local Features | 

NTXR12AA or CCS7 MTP/SCCP For LPP Based Platforms 
NTX041AB CCS7 MTP/SCCP 
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AG1638 - Message Service—Network MWI (continued) 


The Message Service—Network Message Waiting Indicator feature in feature 
package NTX797AA requires the following feature packages: 


Feature package prerequisites 


Feature package Feature package name 


NTX001AA Common Basic 

NTX100AA Integrated Business Networks - Basic (IBN) 
NTX106AA IBN - Proprietary Business Set 

NTX108AA IBN - Display Features 

NTX142AA DS-1 64 KBPS Clear 

NTX244AA or Sequential Trunk Selection 

NTX244AB Enhanced Sequential Trunk Hunting 
NTX270AA New Peripheral Maintenance Package 
NTX750AB-AD ISDN Basic Access 


NTX790AB or AC ISDN - Primary Rate Access Base 
NTX901AA Local Features | 


NTXA68AA Network Message Service 


Description 


This feature allows a message service to activate and deactivate the message 
waiting indicator (MWI) of a subscriber located on another node. The nodes 
must support transaction capability application part (TCAP) communications, 
in accordance with the voice message storage and retrieval. They must also 
have Integrated Services Digital Network (ISDN) primary rate interface (PRI) 
connections. These connections provide the message service with subscribers’ 
directory numbers (DN) and names, if the names are available. 


This feature also allows ISUP PRI trunks to terminate on a Simplified Message 
Desk Interface (SMDID), thereby allowing SMDI to activate and deactivate the 
MWI of subscribers located on other nodes. 


Background information 
Message waiting (MWT) notifies station users that a message is queued 
against their DN. The station users dial an access code to access the message 
service and retrieve messages. 
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AG1638 - Message Service—Network MWI (continued) 


TCAP builds and sends messages instructing the user's node to activate or 
deactivate an MWI. The messages are sent in packages. A TCAP package's 
destination address is obtained through global title translation (GTT), 
performed by the signaling connection control part (SCCP) of the Common 
Channel Signaling No. 7 (CCS7) network. 


GTT provides a TCAP package's destination address in a called party address 
(CDPA). A CDPA consists of a combination of point code (PC), subsystem 
number (SSN), and global title (GT). The PC identifies each node within a 
CCS7 network and routes messages through the network. The SSN and GT 
identify each TCAP application. 


SMDI connects a voice messaging system (VMS) or text messaging system 
(TMS) to an end office. Users forward their phones to the message desk, where 
callers can leave messages on an answering machine (VMS) or with an 
operator (TMS). Users retrieve messages from VMS by dialing the SMDI 
directly and entering a password. They retrieve TMS messages by logging 
onto the SMDI system and reading the messages posted by the attendant. 


ISDN PRI connects a DMS—100 ISDN switch to another switching node. PRI 
allows users to access advanced network services for voice and data. 


Operation 


The message center's node is called the host; the subscriber's node is called the 
server. Hosts must be connected to servers by a TCAP (for message centers) 
or an ISUP PRI (for SMDIs). 


Message service—When a message service initiates a request to activate a 
subscriber's MWI, the following occur: 


1. From the host node, the VMS requests message waiting activation on the 
server node. The request includes the following data: 


e destination DN 

e calling DN 

e message service identification (ID) DN 
e time stamp 

e calling name 

e message service ID name 

e message service type 


The calling name, message service ID name, and message service type are 
not used by the Message Service—Network Message Waiting Indicator 
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AG1638 - Message Service—Network MWI (continued) 


feature, but the calling and message service ID names may be used by 
feature “Network Name Display. 


2. The server node successfully activates the subscriber's message waiting 
lamp. 


3. The server node sends the host a TCAP acknowledgement of successful 
activation. 


Network MWI deactivation is handled the same way. The host node VMS 
system initiates the deactivation request, sending the same data except for 
omitting the timestamp. The server node deactivates the message waiting lamp 
and notifies the host. 


SMDI—When an SMDI agent initiates a request to activate a subscriber's 
MWI, the following occur: 


1. From the host node, the SMDI agent enters the command OP:MWI ffff! 


2. GTT uses the subscriber's DN and the null SSN to provide a destination 
point code (DPC). 


3. TCAP then sends a package with the DPC and the instructions MWT on 
to the server node. 


4. On the server node, the DPC is used to locate the subscriber's line. 
Message waiting is then activated. 


5. The server node sends the host a TCAP acknowledgement of successful 
activation. 


The message recipient retrieves messages by dialing the SMDI directly, 
dialing a Call Request Retrieval (CRR) code, or for a Meridian business set 
(MBS) user by pressing the CRR key. Network Message Service (NMS) CRR 
uses reverse DN translations to route the call to the message desk. Therefore, 
tables CUSTNTWK, DNREGION, and DNREVXLA must be properly 
datafilled in order for network CRR to work. For more information on reverse 
DN translations, see feature “Network Dial Plan Display” in the Translations 
Guide. 


The message is not automatically removed from the subscriber's message 
queue when the messages are retrieved with CRR. Instead, they are removed 
when the MWI is deactivated. 


Network MWI deactivation is handled similarly to activation. An SMDI agent 
enters the command RMV:MWI ffff. A DPC is generated by GTT, and a TCAP 
package with the instructions MWT OFF is sent to the server. 
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AG1638 - Message Service—Network MWI (continued) 


TCAP negative acknowledgement—If a request to activate or deactivate an 
MWI fails, TCAP returns a negative acknowledgement to the host. The 
acknowledgement indicates one of the following reasons for failure: 


Task Refused indicates that the server is overloaded and cannot currently 
handle the request. 


Unassigned DN indicates that the destination DN is not currently assigned 
to an active interface. 


Notification Unavailable to Destination DN indicates that the destination 
DN cannot be immediately notified, perhaps because the DN is 
temporarily out of service. 


VMSR ID did not Match User Profile indicates that the destination DN is 
not a subscriber of the VMSR system. 


Activation/deactivation by the end-user 


Activation and deactivation of an end—user's MWI is initiated by VMS or 
SMDI. 


Users forward their phones to VMS or SMDI by pressing the appropriate call 
forward button and dialing the SMDI directory number. Users retrieve VMS 
messages by dialing the message service directly and talking to an agent. 


Users retrieve SMDI messages in one of the following ways, depending on 
their stations and SMDI configuration: 


Users dial the SMDI desk directly to retrieve their messages through an 
agent. 


Users dial a CRR code to retrieve their messages from an answering 
machine. 


MBS users press the CRR key to retrieve their messages from an 
answering machine. 


Limitations and restrictions 


The limitations and restrictions of the Message Service—Network Message 
Waiting Indicator feature include the following: 


SMDIs that are datafilled in table SLLNKDEV with the NUMOFDIGS 
option set to 10 digits can convert a seven—digit DN to a ten—digit DN 
outside the numbering plan area (NPA) of the SMDI. Therefore, such an 
SMDI can activate and deactivate a MWI of a subscriber residing outside 
the NPA of the SMDI. However, SMDIs that are datafilled in table 
SLLNKDEV with the NUMOFDIGS option set to 7, convert a seven—digit 
DN to a ten-digit DN by assigning the NPA of the SMDI to the DN. Thus, 
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AG1638 - Message Service—Network MWI (continued) 


the SMDI can activate an MWI of a subscriber residing inside the NPA of 
the SMDI. 


SMDI users cannot delete messages or turn off their MWIs with the CRR 
option; only the SMDI agent can deactivate the MWI. 


The Call Request Delete All (CRDA) option deactivates the MWI, but does 
not remove the messages queued against subscribers’ stations. Only the 
message service or SMDI agent can delete messages from the queue. 


Security codes are not screened on the server node when a subscriber's 
MWl is turned on; therefore, an unauthorized user could activate an MWI. 
However, security codes are screened, when a subscriber's MWI is turned 
off, thereby eliminating the risk of an unauthorized Network Message 
Service deactivating MWIs and deleting subscribers' messages. 


This feature does not direct MWT notification to a remote phone. The 
MWT and Message Service—Network Message Waiting Indicator 
features are separate. 


Feature interactions 
The Message Service—Network Message Waiting Indicator feature interacts 
with SMDI, but does not change its function. In addition, the following 
features are affected: 


CRDA—CRDA turns off a user's MWI, but does not remove messages 
from that user's queue. Messages are removed when the message service 
or SMDI deactivates the message waiting indicator. 


Message service - list management—With the message list editing (MLE) 
environment, a user can identify a call requestor's name and DN before 
retrieving the message. When an MLE subscriber's MWT is activated by 
the Message Service—Service—Network Message Waiting Indicator 
feature, the name and DN of the message service is displayed when the 
subscriber retrieves messages. 


Office parameters 
Network MWI introduces two office parameters. Two current parameters must 
change for this feature. Parameters NO_OF_SMALL_EXT_ BLKS and 
NO_OF_XLARGE_EXT_BLKS must change. The new parameters are 
NMS_ ACKNOWLEDGMENT_TIMEOUT and 
DYNAMIC_MEMORY_SIZE. All four parameters are in Table OFCENG. 
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AG1638 - Message Service—Network MWI (continued) 
Datafill procedure for office parameters on server nodes 
The following procedure identifies the server node datafill for the office 


parameter Dynamic_Memory_Size. 


Datafill procedure for table OFCENG on server nodes 


Parameter Explanation and action 


Dynamic_Memory_Size This parameter is used to specify the amount of memory available for 
several pools of memory. It has immediate activation and can be re-sized 
at any time. The parameter value may need to be increased as the number 
of Network MWI subscribers increases. Use the call processing tool 
manager (CPPOOLMGR) to see the current parameter value. 


Datafill example for table OFCENG 


The following example of a MAP display shows sample server node datafill 
for the office parameter Dynamic_Memory_Size. 


DYNAMIC MEMORY SIZE PARM 


PARM MEMORY IN KBYTES VAST AREAS 
SIZE Total USED Total USED 
15MB 15360K 2112K 13% 240 33K 13% 


POOLS IN ALARM 


POOL FTRQ2WPERMS is in alarm for a POOL_LIMIT alarm 
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AG1638 - Message Service—Network MWI (continued) 


Datafill procedure for office parameters on host nodes 


The following procedure identifies the host node datafill for the office 
parameters NUS_-ACKNOWLEDGEMENT_TIMEOUT, 
NO_OF_XLARGE_EXT_BLKS and NO_OF_SMALL_EXT_BLKS. 


Datafill procedure for table OFCENG on host nodes 


Parameter Explanation and action 


NMS_ACKNOWLEDGE _ Set this parameter to the number of seconds that an NMS TCAP request 

MENT_TIMEOUT waits for acknowledgement from the server node during an MWT 
activation or deactivation. The number of seconds can be between 0 and 
32 767; 3 seconds is the default. Assigning 0 has the effect of disabling the 
timeout mechanism: the TCAP request will never time out. 


For the formula for this parameter, refer to the Office Parameters 
Reference Manual, 297-1001-455. 


Any change in this parameter takes effect immediately. A restart is not 
necessary. 


Underestimating causes too many NMS TCAP requests to time out. 
Overestimating causes transaction IDs to exist for too long, which in turn 
exhausts the supply of transaction IDs. 
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AG1638 - Message Service—Network MWI (continued) 


NO_OF_XLARGE_EXT 
_ BLKS 


NO_OF_SMALL_EXT. 
BLKS 


Datafill procedure for table OFCENG on host nodes 


This parameter indicates the number of extra large extension blocks used 
by NMS. It can be from 0 to 32 767 blocks. The default is 16 blocks. 


For the formula for this parameter, refer to the Office Parameters 
Reference Manual. 


An extra large extension block is used each time a Message 
Service—Network Message Waiting Indicator feature activation or 
deactivation times out. 


To accommodate NMS, this parameter should be increased by 
NMS_ACKNOWLEDGEMENT_TIMEOUT times the sum of all requests in 
an office's SMDIs per second. 


Parameter autoprovisioning was added in TL10. A parameter increase 
change is immediate. Changes associated with decreases require a cold 
restart. 


Each extra large extension block uses 200 words of storage; therefore, the 
number of words required is NO_OF_XLARGE_EXT_BLKS times 200. 


This parameter is associated with the EXT OM group. To verify that it is set 
and working properly, ensure that EXTOVEL is not 0. If it is, the parameter 
is too low. Also, EXTHI records the maximum number of extension blocks 
in simultaneous use during a given transfer period. 


Underestimating this parameter prevents the Message Service—Network 
Message Waiting Indicator feature from functioning properly. 
Overestimating it can waste storage. 


This parameter indicates the number of small extension blocks used by 
NMS when a request times out. It can be from 0 to 32 767 blocks. The 
default is 16 blocks. 


For the formula for this parameter, refer to the Office Parameters 
Reference Manual. 


Parameter autoprovisioning was added in TL10. A parameter increase 
change is immediate. Changes associated with decreases require a cold 
restart. 


Each small extension block uses 10 words of storage; therefore, the 
number of words required is NO_LOF_SMALL_EXT_BLKS times 10. 


This parameter is associated with the EXT OM group. To verify that it is set 
and working properly, ensure that EXTOVEL is not 0. If it is, the parameter 
is too low. Also, EXTHI records the maximum number of extension blocks 
in simultaneous use during a given transfer period. 


Underestimating this parameter prevents Network MWI from functioning 
properly. Overestimating it wastes storage. 
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AG1638 - Message Service—Network MWI (continued) 


Datafill example for table OFCENG 
The following example shows datafill for office parameters 
NMS_ACKNOWLEDGEMENT_TIMEOUT, 
NO_OF_XLARGE_EXT_BLKS, and NO_OF_SMALL_EXT_BLKS. 


Datafill example for table OFCENG 


Example of a MAP display: 


PARMNAME PARMVAL 
NMS_ACKNOWLEDGEMENT_TIMEOUT 3 
NO_OF_XLARGE_EXT_BLKS 16 
NO_OF_SMALL_EXT_BLKS 16 


Datafill sequence 


The following tables are affected by the Message Service—Network Message 
Waiting Indicator feature. 


Data tables required for Network MWI 
C7NETSSN 

C7GTTYPE 

C7GTT 

C7LOCSSN 

C7RPLSSN 

C7RSSCRN 


Datafill procedure for table C7-NETSSN 


The following procedure identifies the datafill for table C7NETSSN. This 
procedure contains only those fields that apply to Message Service—Network 
Message Waiting Indicator. Refer to the Translations Guide for a description 
of the other fields. 


Datafill procedure for table C-(NETSSN 


Field Subfield Explanation and action 

SSNAMES Field SSNAMES is comprised of the subfields SSNAME and 
SSNUMBER. The two subfields in SSNAMES identify a 
subsystem. 
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AG1638 - Message Service—Network MWI (continued) 


Datafill procedure for table C-(NETSSN 


SSNAME Enter NMS, the predefined subsystem name to be used by 
Message Service—Network Message Waiting Indicator. 


SSNUMBER Enter a subsystem number from 2 to 255. This number must be 
unique within table C7LOCSSN. 


Datafill example for table C7-(NETSSN 
The following example shows sample datafill from table C7NETSSN. 


Datafill example for table C7NETSSN 


Example of a MAP display: 


PCNAME SSNAMES 


S2_RTE (NMS 123)$ 


Datafill procedure for table C7GTTYPE 


The following procedure identifies the datafill for table C7GTTYPE. This 
procedure contains only those fields that apply to Message Service—Network 
Message Waiting Indicator. Refer to theTranslations Guide for a description of 
the other fields. 


Datafill procedure for table C7GTTYPE 
Field Subfield Explanation and action 


GTTNAME Enter NMSGT, the global title translation name used by the 
Message Service—Network Message Waiting Indicator feature. 


GTTID Enter NMSGT, the global title translation identifier used by the 
Message Service—Network Message Waiting Indicator feature. 


Datafill example for table C7GTTYPE 
The following example shows sample datafill from table C7GTTY PE. 


Datafill example for table C7GTTYPE 


Example of a MAP display: 


GTTNAME 


GTTID 


NMSGT ANSI7 252 ( NMSGT) $ 
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AG1638 - Message Service—Network MWI (continued) 


Datafill procedure for table C7GTT 
The following procedure identifies the datafill for table C7GTT. This 
procedure contains only those fields that apply to Message Service—Network 
Message Waiting Indicator. Refer to theTranslations Guide for a description of 
the other fields. 


Datafill procedure for table C7GTT 
Field Subfield Explanation and action 


GTTKEY This key field is made up of three subfields. Only subfield 
GTTNAME is changed by the Message Service—Network 
Message Waiting Indicator feature. 


GTTNAME Enter the global title translation name NMSGT. 


GTTRSLT Enter PCSSN. This field is composed of up to eight subfields. 
Only subfield SSNAME is changed by the Message 
Service—Network Message Waiting Indicator feature. 


SSNAME Enter the predefined subsystem name NMS. 


Datafill example for table C7GTT 
The following example shows sample datafill from table C7GTT. 


Datafill example for table C7GTT 


Example of a MAP display: 


GTTKEY GTTRSLT 


NMSGT 0 9 


PCSSN (S2_RTE NMS 80) $ GT 
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AG1638 - Message Service—Network MWI (continued) 


Datafill procedure for table C7LOCSSN 


The following procedure identifies the datafill for table C7LOCSSN. This 
procedure contains only those fields that apply to Message Service—Network 
Message Waiting Indicator. Refer to the Translations Guide for a description 
of the other fields. 


Datafill procedure for table C7LOCSSN 
Field Subfield Explanation and action 


SSNAME Enter NMS, the predefined subsystem name to be used by the 
Message Service—Network Message Waiting Indicator feature. 


Datafill example for table C-LOCSSN 
The following example shows sample datafill from table C7LOCSSN. 


Datafill example for table C7LOCSSN 


Example of a MAP display: 


SSNAME 


NMS 


Datafill procedure for table C7RPLSSN 


The following procedure identifies the datafill for table C7RPLSSN. This 
procedure contains only those fields that apply to Message Service—Network 
Message Waiting Indicator. Refer to theTranslations Guide for a description of 
the other fields. 


Datafill procedure for table C7-RPLSSN 


Field Subfield Explanation and action 


SSNAME Enter NMS, the predefined subsystem name to be used by the 
Message Service—Network Message Waiting Indicator feature. 
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AG1638 - Message Service—Network MWI (continued) 


Datafill example for table C7RPLSSN 
The following example shows sample datafill from table C7RPLSSN. 


Datafill example for table C7RPLSSN 


Example of a MAP display: 


SSNAME 


EPLIST 


NMS SP3 SP4 N & 


Datafill procedure for table C7RSSCRN 


The following procedure identifies the datafill for table C7RSSCRN. This 
procedure contains only those fields that apply to Message Service—Network 
Message Waiting Indicator. Refer to the7ranslations Guide for a description of 
the other fields. 


Datafill procedure for table C7-RSSCRN 


Field Subfield Explanation and action 


SSNAME Enter NMS, the predefined subsystem name to be used by the 
Message Service—Network Message Waiting Indicator feature. 


Datafill example for table C7-RSSCRN 
The following example shows sample datafill from table C7RSSCRN. 


Datafill example for table C7RSSCRN 


Example of a MAP display: 


PCSSN PCNAMES 


S2_RTE NMS & 


Operational measurements 


The FTRQ OM group is affected by the Message Service—Network Message 
Waiting Indicator feature, and the NETMSG group is introduced. 


FTRQ—The FTRQ provides OM data on usage and traffic of feature queuing 
software resources required for Meridian Digital Centrex (MDC) features. 
These measurements are on an office—wide basis. 
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The Message Service—Network Message Waiting Indicator feature adds two 
new key fields: FTRQ32WAREAS and FTRQ32WPERMS. 


Three registers are pegged for each key field. FTRQSEIZ is pegged each time 
a request for an FTRQ block of specific size is successful. FTRQOVFL is 
pegged each time a request for an FTRQ block of specific size fails because 
none are available. FTRQHI indicates the highest number of simultaneous 
usage for an FTRQ block of specific size during the current transfer period. 


NETMSG—The NETMSG group records conditions that result from NMS. 
These OMs help detect potential problem areas. 


The following table describes the registers for NETMSG. 


OMs for group NETMSG 


Register Explanation 


NMSTIME On host nodes, counts the number of times an NUS TCAP 
request times out. This is a peg count. 


A peg on this register can be caused by a TCAP request being 
lost before reaching a server or by a TCAP acknowledgement 
being lost before reaching a host. This register is unaffected by 
office parameters. 


NMSDENL On host nodes, counts the number of times an NUS TCAP 
request receives a negative acknowledgement. This is a peg 
count. 


A peg on this register can be caused by a message service 
being unable to alter a subscriber's MWI. 
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AG1638 - Message Service—Network MWI (continued) 


Log reports 


OMs for group NETMSG 


Register Explanation 


NMSINVAD On host nodes, counts the number of times a message service 
receives addresses that are not valid. This is a peg count. 


A peg on this register can be caused by a message service 
agent entering an incorrect DN or by a message service 
generating an incorrect DN. This register is unaffected by office 
parameters. 


Log NMS100: INVALID ADDRESS FROM NMS is generated 
each time this register is pegged. 


NMSVACT On server nodes, counts the number of NMS requests received 
for vacant subscriber DNs. This is a peg count. 


A peg on this register can be caused by a dropped subscriber 
or by a message service generating a valid, but incorrect, 
address. This register is unaffected by office parameters. 


Log NMS101: VACANT NMS SUBSCRIBER DN is generated 
each time this register is pegged. 


The logs associated with this parameter are: NMS100, NMS101, NMS102, 
NMS103, and NMS104. The logs generate if the optional NMS subsystem is 
present. The logs provide information only and require no action. 


NMS100 - INVALID ADDRESS FROM NMS generates at a host when a 
message service generates an address that is not valid. The log relates to the 
OM register NMSINVAD of OM group NMS. The format of the log report 
follows: 


NMS100 mmmdd hh:mm:ss ssdd INFO INVALID ADDRESS FROM 
NMS 


INVALID ADDR = nnnnnnnnnn 
An example of an NMS100 log report follows: 


NMS100 JUNO9 08:12:57 1234 INFO INVALID ADDRESS FROM 
NMS 


INVALID ADDR = 9999999999 
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NMS101 - VACANT NMS SUBSCRIBER DN generates at a server when a 
Network MWI request specifies a vacant subscriber DN. This log relates to 
OM register NMSVACT of OM group NMS. The format of the log report 
follows: 


NMS101 mmmdd hh:mm:ss ssdd INFO VACANT NMS SUBSCRIBER 
DN 


INVALID ADDR = nnnnnnnnnn 
An example of an NMS101 log report follows: 


NMS101 JUNO9 09:12:57 1235 INFO VACANT NMS SUBSCRIBER 
DN 


INVALID ADDR = 8153692666 

NMS102 - NOTIFICATION UNAVAILABLE generates at a server when there 
is no notification to the subscriber DN for a short term reason. An example of 
a short term reason is that the line is temporarily out of service. The NMS102 
log detects problems that cause a network message service to send incorrect 


DNs.The format of the log report follows: 


NMS102 mmmdd hh:mm:ss ssdd INFO NOTFICATION 
UNAVAILABLE 


SUBSCRIBER DN = nnnnnnnnnn 
An example of an NMS102 log report follows: 


NMS102 JUNO9 09:12:57 1236 INFO NOTIFICATION 
SUSBSCRIBER DN 


SUBSCRIBER DN = 8155262666 

NMS 103 -NOTIFICATION UNAVAILABLE TO DESTINATION DN generates 
at a server when a transaction capabilities application part (TCAP) response 
receives a component return error. This log relates to OM registers NUS VACT 


and NMSINVAD of OM group NMS. The format of the log report follows: 


NMS103 mmmdd hh:mm:ss ssdd INFO NOTFICATION 
UNAVAILABLE TO DESTINATION DN 


SUBSCRIBER DN = nnnnnnnnnn 
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An example of an NMS103 log report follows: 


NMS103 JUNO9 09:12:57 1236 INFO NOTIFICATION 
UNAVAILABLE TO DESTINATION DN 


SUBSCRIBER DN = 8156862666 


NMS 104 -TRID UNRELEASE REPORT generates when the transaction 
identifier (TRID) cannot release by the identifier pool (IDPL) functionality 
after sending a transaction capabilities application part (TCAP) message. The 
IDPL functionality dynamically creates the TRID. The format of the log report 
follows: 


NMS104 mmmdd hh:mm:ss ssdd INFO 
TRID_UNRELEASE REPORT 


TRANSACTION ID CANNOT RELEASE 
An example of an NMS104 log report follows: 


NMS104 JUNO9 09:12:57 1236 INFO 
TRID_UNRELEASE_REPORT 


TRANSACTION ID CANNOT RELEASE 


Billing 
The Message Service—Network Message Waiting Indicator feature does not 
affect billing. 


Service orders 


The Message Service—Network Message Waiting Indicator feature does not 
affect service orders. 
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AG1980 - RES SMDI CLID Suppression 


Name 

RES SMDI CLID Suppression 
Number 

AG1980 
Package 

NTXNO7AA (enhanced by AF3679) 
BCS 


BCS31 and up 


Feature package prerequisites 
The RES SMDI CLID Suppression feature requires the following feature 


packages: 
Feature package prerequisites 
Feature package Feature package name 
NTXOO0AA Bilge 
NTX001AA Common Basic 
NTX100AA Integrated Business Networks - Basic (IBN) 
NTX730AA Multilink ASCII Device Driver 
NTX732AA Simplified Message Desk Interface (SMDI) 
NTX901AA Local Features | 


Description 
A restricted DN cannot be delivered to a terminating party. This feature blocks 
the delivery of restricted numbers to the SMDI. Prior to this feature, both 
restricted and unrestricted DNs were delivered to the SMDI. 


Background information 
The SMDI connects a VMS or TMS to an end office. Users forward their 
phones to the message desk, where callers can leave messages on an answering 
machine (VMS) or with an operator (TMS). By default, both the calling and 
forwarding party's DNs are delivered to the SMDI. 
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AG1980 - RES SMDI CLID Suppression (continued) 


Operation 


All calls forwarded to the SMDI are answered by a forwarding party's personal 
greeting, a generic system greeting, or an attendant. If the LASTFWDN option 
is datafilled for an SMDI link, the SMDI takes a message for the final 
forwarding party. Otherwise, the original forwarding party receives the 
message. 


A DN is restricted if either of the following is true: 


e The DN is assigned the SUPPRESS option in tables NETNAMES, 
DNGRPS, or DNATTRS. 


e The DN is on a Custom Local Area Signalling Services (CLASS) line that 
has the Calling Number Delivery Blocking (CNDB) option, and the caller 
chose to block the number when placing the call. 


Blocking is specified through the DNSUPPR option in table SELNKDEV, 
which has two subfields, CALLING and FWDING. Each subfield accepts the 
following values: 


e NEVER - never block the party's DN, even if it is restricted 
e CONDITNL - block restricted DNs; don't block unrestricted DNs 


In addition, the CALLING subfield accepts INDIRECT, which causes indirect 
calls to be blocked, even if they are unrestricted. (An indirect call to the SMDI 
is one that is forwarded there by another party.) 
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AG1980 - RES SMDI CLID Suppression (continued) 


The following table shows the DN delivery for different settings of DNSUPPR 


subfields and for all combinations of restricted numbers. 


DN Delivery to the SMDI 
DNSUPPR option 
CALLING 
FWDING subfield | subfield Restricted DNs Delivered DNs 
NEVER 
NEVER CONDITNL 
INDIRECT 
Note: |f the forwarding DN cannot be delivered to the SMDI, neither DN will be 
delivered, even though the CALLING subfield is NEVER or the DN is unrestricted. 
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AG1980 - RES SMDI CLID Suppression (continued) 


DN Delivery to the SMDI 


DNSUPPR option 


CALLING 
FWDING subfield | subfield Restricted DNs Delivered DNs 
neither both 
forwarding neither (see note) 
NEVER 
calling both 
both neither (see note) 
neither both 
forwarding neither (see note) 
CONDITNL CONDITNL 
calling forwarding 
both neither 
neither | forwarding 
_— neither 
INDIRECT 
n forwarding 
—_ neither 


Note: lf the forwarding DN cannot be delivered to the a neither DN will be 
delivered, even though the CALLING subfield is NEVER or the DN is unrestricted. 


Based on datafill and the calling party's initiation of the call, there are three 
possible scenarios for blocking the DN delivery to the SMDI. 


The DNs of both the calling and forwarding parties are blocked. If the 
forwarding party's DN is restricted, the SMDI cannot take a message for 
that party. Therefore, neither DN is delivered to the SMDI. The SMDI 
plays a generic system announcement for the caller and does not take a 
message. 


The calling party's DN is blocked. As long as the forwarding party's DN is 
available, the SMDI can take a message for that party. 


Neither DN is blocked. The SMDI proceeds to take a message for the 
forwarding party. 
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AG1980 - RES SMDI CLID Suppression (continued) 


Activation/deactivation by the end—user 


Users forward their phones to the SMDI by pressing the appropriate call 
forward button and dialing the SMDI directory number. 


If users are on a CLASS line that has the CNDB option, they can chose to 
block or not to block their numbers when placing the call. 


For each SMDI datalink, the DNSUPPR suboptions NEVER, CONDITNL, 
and INDIRECT are activated automatically based on datafill. 


Limitations and restrictions 


Limitations of the RES SMDI CLID Suppression feature include the 
following: 


e With CALLING = CONDITNL and FWDING = NEVER, a restricted 
forwarding DN will never be blocked. However, when that DN originates 
a call to the SMDI to retrieve messages, the DN will be blocked, because 
the calling DN was specified to be conditionally blocked. The user must 
then use CNDB to toggle the suppression of the DN when retrieving 
messages. 


In addition, the limitations of the SMDI and SMDI Enhanced features apply to 
this feature. 


Feature interactions 
This feature interacts with the following features and options: 


e LASTFWDN option 


e If LASTFWDN is datafilled for the SMDI, the blocking level specified in 
the FWDING subfield applies to the final forwarding party. The restriction 
of other DNs in a call forwarding chain has no effect on DN delivery to the 
SMDI. 


e SMDI 


e This feature affects the calling information sent to the SMDI. If FWDING 
= CONDITNL and the forwarding DN is restricted, no call information 
will be delivered to the SMDI. Thus, no message will be taken for the 
forwarding party. If CALLING = CONDITNL, a subscriber with a 
restricted DN may be unable to retrieve messages. 


Office parameters 
The RES SMDI CLID Suppression feature does not affect office parameters. 
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AG1980 - RES SMDI CLID Suppression (continued) 


Datafill sequence 
Table SLLNKDEV is affected by the RES SMDI CLID Suppression feature. 


Data table required for Blocking of restricted number to SMDI 


Table 


SLLNKDEV 


Datafill procedure for table SLLNKDEV 


The following procedure identifies the datafill for table SLLNKDEV. This 
procedure contains only those fields that apply to RES SMDI CLID 
Suppression. Refer to the Translations Guide for a description of the other 
fields. 


Datafill procedure for table SLLNKDEV 


Field Subfield Explanation and action 
XFERS Enter SMDIDATA as the transfer value. 
OPTION Enter DNSUPPR to specify the DN blocking option. 
CALLING Enter one of the following values: NEVER to never block calling 


DNs; CONDITNL to block restricted calling DNs; and INDIRECT 
to always block indirect (forwarded) calls and to conditionally 
block direct (message retrieval) calls to the SMDI. 


FWDING Enter one of the following values: NEVER to never block 
forwarding DNs; and CONDITNL to block restricted forwarding 
DNs. 


Datafill example for table SLLNKDEV 
The following example shows example datafill from table SLLNKDEV. The 
device name SMDII has the DNSUPPR option assigned to it. 


Datafill example for table SLLNKDEV 


Example of a MAP display: 


DEVNAME DEVTYPE XLATION PROTOCOL DRECTION XFERS 


SMDI1 1X89 0 2 NONE NONE INOUTLK (SMDIDATA 
DNSUPPR INDIRECT CONDITNL &) & 
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AG1980 - RES SMDI CLID Suppression (end) 


Operational measurements 


The RES SMDI CLID Suppression feature does not affect operational 
measurements. 


Log reports 

The RES SMDI CLID Suppression feature does not affect log reports. 
Billing 

The RES SMDI CLID Suppression feature does not affect billing. 


Service orders 
The RES SMDI CLID Suppression does not affect service orders. 


297-2051-104 Preliminary 13.01 September 2004 


Name 


Number 


Package 


BCS 


SMDl:features 9-27 


NC0009 - SMDI: Called DN Option and KSH Support 


SMDI: Called DN Option and KSH Support 


Note: This feature is not available for CS 2000 - Compact offices. 
NCO0009 
NTX732AA 


BCS31 and up 


Feature package prerequisites 


Description 


The SMDI - Called DN Option and KSH Support feature requires the 
following feature packages: 


Feature package prerequisites 


Feature package Feature package name 

NTXOO0AA Bilge 

NTX001AA Common Basic 

NTX100AA Integrated Business Networks - Basic (IBN) 
NTX101AA IBN - Enhanced Business Services 
NTX119AA IBN - Message Service 

NTX730AA Multilink ASCII Device Driver 

NTX901AA Local Features | 


The SMDI: Called DN Option and KSH Support feature improves the SMDI 
product in two ways. First, foreach SMDI datalink, customer offices can select 
whether the first or last forwarding party in a call forward chain will be the 
recipient of the message. Second, key short hunt (KSH) overflow calls are 
handled the same as call forward busy calls, and are therefore sent to the SMDI 
with the DN of the originally called party or the last forwarding party. 
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NC0009 - SMDI: Called DN Option and KSH Support (continued) 


Background information 


Operation 


The SMDI connects a VMS or TMS to an end office. Users forward their 
phones to the message desk, where callers can leave messages on an answering 
machine (VMS) or with an operator (TMS). Users retrieve messages from 
VMS by dialing the SMDI directly and entering a password. They retrieve 
TMS messages by logging onto the SMDI system and reading the messages 
posted by the attendant. 


Users set one of three levels of call forwarding to the SMDI: Call Forward 
Universal, which forwards all calls; Call Forward Busy, which forwards calls 
when the user's line is busy; and Call Forward No Answer, which forwards 
calls after a specified number of rings. 


With KSH, calls coming into a key set can be routed to any DN on that set. The 
primary DN (the originally dialed number) is tried first. If that number is busy, 
other numbers in the key set are tried until an idle DN is found or all DNs in 
the key set are unsuccessfully tried. 


All calls forwarded to the SMDI are answered by a forwarding party's 
personal greeting, a generic system greeting, or an attendant. If the 
LASTFWDN option is datafilled for an SMDI link, the SMDI takes a message 
for the final forwarding party. Otherwise, the original forwarding party 
receives the message. 


If the called party's line is busy and the KSH feature is available for the office, 
a key short hunt is initiated. When all DNs in the key set are busy, the call is 
forwarded to the SMDI and the originally called DN in the key set is passed. 


Activation/deactivation by the end—user 


Users forward their phones to the SMDI by pressing the appropriate call 
forward button and dialing the SMDI DN. 


The LASTFWDN option is activated automatically based on datafill in table 
SLLNKDEV. 


The KSH feature is activated automatically based on datafill. 


Limitations and restrictions 


Limitations and restrictions of the SMDI - Called DN Option and KSH 
Support feature include the following: 


e The LASTFWDN option requires both the original and final terminating 
parties to reside on the same switch. In other words, network call 
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NC0009 - SMDI: Called DN Option and KSH Support (continued) 


forwarding calls always report the original forwarding DN to the SMDI, 
regardless of the presence of the LASTFWDN option in table 
SLLNKDEV. 


The KSH to SMDI feature requires both the original and final terminating 
parties to reside on the same switch. In other words, network KSH 
overflow calls are treated as direct calls: the caller receives a generic 
system announcement and cannot leave a message. 


In addition, the restrictions imposed by KSH and Call Forwarding apply to this 
SMDI enhancement feature. 


Feature interactions 
These features interact with the SMDI - Called DN Option and KSH Support 
feature: 


KSH feature KSH overflow calls are sent to the SMDI as call forward busy 
calls. Therefore, a message is taken for the original or final forwarding 
party's DN, depending on the setting of the LASTFWDN option. 


Without the SMDI - Called DN Option and KSH Support feature, KSH 
overflow calls are sent to the SMDI as direct calls. 


LASTFWDN option. With the LASTFWDN option, the final forwarding 
party's DN is presented to the SMDI, and a message is taken for that user. 
If a KSH overflow follows a call forwarding chain, the originally called 
DN in the key set is considered the final forwarding party. 


Without LASTFWDN, the original forwarding party's DN is presented to 
the SMDI. If a KSH overflow initiates a call forwarding chain, the 
originally called number in the key set is presented to the SMDI. 


Three-way Calling. The SMDI: Called DN Option and KSH Support 
feature does not apply to DNs involved in a three-way call. When a 
three—way caller dials a number that is forwarded to the SMDI, the call is 
sent as a direct call, and the caller receives a generic system announcement. 
The same is true for KSH overflow calls routed to the SMDI. 


Office parameters 
The KSHUNT_EXT_BLOCKS parameter of table OFCENG is affected by 
the SMDI - Called DN Option and KSH Support feature. The parameter 
specifies the number of allocated KSH Extension blocks. Valid entries are 
from 0 to 32 767. The default is 1000 blocks. The SMDI - Called DN Option 
and KSH Support feature does not change this office parameter's definition, 
range of values, or default value. However, the data storage allocated for each 
block is increased from six words to eight. 
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NC0009 - SMDI: Called DN Option and KSH Support (continued) 


A change in this parameter requires a cold or reload restart before the new 
value is effective. 


Datafill sequence 


Table SLLNKDEYV is affected by the SMDI - Called DN Option and KSH 
Support feature. 


Data table required for SMDI: Called DN Option and KSH Support 
Table 


SLLNKDEV 


Datafill procedure for table SLLNKDEV 


The following procedure shows the datafill for table SLLNKDEV. This 
procedure contains only those fields that apply to SMDI - Called DN Option 
and KSH Support. Refer to theTranslations Guide for a description of the other 
fields. 


Datafill procedure for table SLLNKDEV 


Field Subfield Explanation and action 
XFERS Specify a transfer value of SMDIDATA. 
OPTION Enter LASTFWDN to identify the last forwarding party as the 


recipient of the message. Without this value, the original 
forwarding party is used. 


Datafill example for table SLLNKDEV 


The following example shows sample datafill for table SLLNKDEV. The 
device name VMSLINK has the LASTFWDN option assigned to it. 


Datafill example for table SLLNKDEV 


Example of a MAP display: 
DEVNAME DEVTYPE XLATION PROTOCOL DRECTION 


XFERS 


VMSLINK 1X67 8 3 NONE NONE INOUTLK 
(SMDIDATA LASTFWDN $) $ 


Operational Measurements 


The SMDI - Called DN Option and KSH Support feature does not affect 
operational measurements. 
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NC0009 - SMDI: Called DN Option and KSH Support (end) 


Log reports 


The SMDI - Called DN Option and KSH Support feature does not affect any 
logs. 


Billing 
The SMDI - Called DN Option and KSH Support feature does not affect 
billing. 


Service orders 


The SMDI - Called DN Option and KSH Support feature does not affect 
service orders. 
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AJ1538 - Message Waiting Indicator - PRI 


Name 

Message Waiting Indicator - PRI 

Note: This feature is not available for CS 2000 - Compact offices. 

Number 

AJ1538 
Package 

NTX797AA 
BCS 


BCS33 and up 


Feature package prerequisites 


The Message Waiting Indicator - PRI feature requires the following feature 
packages: 


Feature package prerequisites 


Feature package Feature package name 


NTX001AA Common Basic 

NTX100AA Integrated Business Networks - Basic (IBN) 
NTX106AA IBN - Proprietary Business Set 

NTX108AA IBN - Display Features 

NTX142AA DS-1 64 KBPS Clear 

NTX244AA or Sequential Trunk Selection 

NTX244AB Enhanced Sequential Trunk Hunting 
NTX270AA New Peripheral Maintenance Package 
NTX750AB-AD ISDN Basic Access 


NTX790AB or AC ISDN - Primary Rate Access Base 
NTX901AA Local Features | 


NTXA68AA Network Message Service 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


Description 


The Message Waiting Indicator - PRI feature provides a visual sign or a 
stuttered dial tone indicating that a message has been left at an SMDI for busy 
or unavailable clients. When a message is left at an SMDI, the MWI is 
activated at the client's set. Once the client retrieves the message, the MWI is 
deactivated. 


The Message Waiting Indicator - PRI feature allows an SMDI to leave a 
message when the calling and called parties are on switches connected by PRI 
trunks or by a combination of PRI trunks and CCS7 signaling links. 


SMDI leaves a message by sending TCAP messages. The Message Waiting 
Indicator - PRI feature routes TCAP messages through table MSGRTE. By 
routing TCAP messages through table MSGRTE, PRI, CCS7, or PRI/CCS7 
networks are supported. 


Background information 


The MWl is currently available across a network. An SMDI on one switch can 
alter the state of an MWI on another switch with a TCAP message. Originally, 
TCAP messages could only be transported over a pure CCS7 network and 
routed in the GTT of the destination DN. GTT is a parameter in a TCAP 
message. 


Simplified Message Desk Interface 


SMDI provides a central answering service by integrating call forwarding 
(CFW), uniform call distribution (UCD), and Message Waiting (MWT). An 
SMDI is made up of a group of UCD agents who receive information on 
incoming calls through a dedicated datalink interface. (The incoming 
information includes the calling party number, the forwarding from station 
number, and the type of call forwarding.) 


SMDI allows a user to 

e forward incoming calls to a message desk 

e be notified if any messages have been taken 

e retrieve those messages from the message desk 

e optionally block DNs from being presented to an SMDI 

The DMS-—100 CFW feature enables a user to forward calls to another DN 
when no one is available to answer calls. The DMS—100 MWT feature enables 


a caller to set up a please call me request. The user identifies the please call me 
request by a message waiting lamp or by a stuttered dial tone. 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


SMDI overview 


The following figure shows how an SMDI integrates CFW, MWT, and UCD. 


Set 


Message Waiting 
Indicator on/off 


Incoming call(s) 


Call to retrieve for user 
messages 


Call Forwarding 


Call routed to 
message 
desk 


Message desk 


Uniform call distribution Calls to message desk 


lines 


Message Datalink Call detail messages to 
waiting interface message desk system 
Simplified Message Message Waiting on/off 


Desk Interface notification from 
message desk system 


Message waiting indicator 


Operation 


Prior to the Message Waiting Indicator - PRI feature, the MWT feature was 
only available across a network. With TCAP messages, an SMDI on one 
switch could alter the state of a MWI on a separate switch. 


The Message Waiting Indicator - PRI feature alters the method of routing the 
TCAP messages. The original application of MWI routed the messages in the 
GTT of the destination DN. With the Message Waiting Indicator - PRI feature, 
TCAP messages are routed through table MSGRTE. Table MSGRTE is 
datafilled with entries based on the destination DN and the destination network 
name. By routing TCAP messages through table MSGRTE, transportation of 
messages over a PRI, CCS7, or PRI/CCS7 networks is possible. 


The Message Waiting Indicator - PRI feature is optional on a network name 
basis. A new option, NMSTBRTE, is added to field OPTION in table 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


NETNAMES. With field OPTION datafilled NMSTBRTE, TCAP messages 
will be routed through table MSGRTE. 


The following figure shows how TCAP messages are routed over a PRI/CCS7 
network. 


Routing TCAP messages 


table 


MSGRTE MSGRTE MSGRTE 
CCS7 link PRI link 


TCAP message table TCAP message table 


Table MSGRTE 


Table MSGRTE determines where a message will be routed. This table 
performs a function similar to the translation and routing tables used by call 
processing. The difference, and thus the need for a distinct table, is that this 
table is concerned with routing messages and not with establishing call 
connections. All switches in the path must have appropriate datafill in table 
MSGRTE. 


If the NMSTBRTE option is datafilled in table NETNAMES, table MSGRTE 
must be datafilled so TCAP messages can be routed correctly. 


DMS-100 Family MDC SMDI Setup and Operation SN04 and up 


9-36 SMDI:features 


AJ1538 - Message Waiting Indicator - PRI (continued) 


The following example shows three tuples from table MSGRTE. 


Example of a MAP display: 


MSGRTKEY 


PUBLIC 427 446 SS7 SWITCHBPC 
PUBLIC 340 350 PRA K2KDT164CLP1 
PUBLIC 380 395 LOCAL 3 N $ 


Datafill example for table MSGRTE 


MSGRTRES 


oo 
zz 


% 
Z 


Table MSGRTE is indexed by a three—field key consisting of a network 
identifier (NETID), and two digit string fields (FROMDIGS and TODIGS). 
The digit strings determine a range of digits. The data in the table is a list of 
routes made up of one to four route elements. Each route element in the route 
list uses a route selector: LOCAL, PRA, or SS7. The route selector determines 
where the MWI will be routed as follows: 


LOCAL 


PRA 


SS7 


This route selector is used to route messages that should 
terminate within the switch. This selector also specifies how 
many digits, if any, should be deleted from the destination 
address in the message information and what digits, if any, 
should be prefixed to the destination address. If LOCAL is 
chosen as a selector, it must be the only route element in the 
route list. 


This route selector is used to route messages to another switch 
over the D-channel on a PRI trunk group. This selector also 
specifies how many digits, if any, should be deleted from the 
destination address in the message information before sending 
the message and what digits should be prefixed to the 
destination address. If necessary, the option NEWNET can be 
datafilled to specify that the network identifier in the destination 
address should be replaced with a different network identifier. 
This allows a message to be received on one network and sent 
out on another. 


This route selector is used to route messages to another switch 
over a CCS7 link. This selector also specifies how many digits, 
if any, should be deleted from the destination address in the 
message information and what digits should be prefixed to the 
destination address. If necessary, the option NEWNET can be 
datafilled to specify the network identifier. This allows a 
message to be received on one network and sent out on 
another. 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


When the selector is primary rate access (PRA), a PRI facility message is 
created and sent to the PRI facility process in the next switch. When the 
selector is SS7, an signaling connection control point (SCCP) unit data 
message is created and sent to the interwork SCCP subsystem in the switch. 
These messages contain the TCAP information needed by the MWI 
application. 


Table MSGRTE routing 


table MSGRTE 


LOCAL 


PRA PRI facility message ——— To next 
switch 


SCCP unit data message —> 


Routing through table MSGRTE 
Network MWI will not send its messages through the SCCP subsystem 
network message service (NMS) if option MWRTBYTE is selected in table 
NETNAMES. The terminating DN and the network name of the terminating 
DN are used as an index into table MSGRTE. Table MSGRTE will be 
datafilled with the specific CCS7 link or PRI D-channel to be used to route the 
message. 


If the TCAP message is to be routed over a PRI D—channel, a PRI facility 
message is constructed with the TCAP message and is sent to a PRI facility 
process at the next switch. 


If the TCAP message is routed over a CCS7 signaling link, the TCAP message 
will be sent to INTERWRK SCCP subsystem at the next switch. 
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If table MSGRTE has no entry for the network and the digits specified, the 
message will not be routed. 


Note: With the Message Waiting Indicator - PRI feature, the NMS 
subsystem will not be required. Customers wanting to use this subsystem 
should not enable the MWRTBYTE option in table NETNAMES. 


Incoming messages 
NMS TCAP messages can be received by one of the following: 


e PRI facility process 
e INTERWRK SCCP subsystem 
e SCCP NMS subsystem 


The message will be received by the PRI facility process if an NMS TCAP 
message is sent over a PRI D-channel. NMS TCAP messages sent over CCS7 
links will be received by the SCCP NMS or the INTERWRK SCCP 
subsystem. 


PRI facility process 

The PRI facility process was created by Network ring again (RAG) to accept 
connection free PRI messages received from a PRI D-channel. Within these 
PRI messages is a TCAP message. 


These TCAP messages have information relating to the following: 
e NMS 

e Network Automatic Call Distribution (NACD) 

e Network RAG 


The facility ID in the TCAP message determines which feature decodes the 
TCAP message. 


The PRI facility process is invoked when a PRI message with a null call 
reference is received from a PRI D-channel. Table MSGRTE routes TCAP 
messages if the PRI facility message indicates that the TCAP message contains 
information for the NMS. If the message is to route locally, the TCAP message 
will be removed from the PRI facility message and passed to the feature 
specified by the facility identifier. 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


TCAP incoming to PRI facility proces 


table MSGRTE 


CCS7 


Local 


Message waiting 


PRI facility 
process 


INTERWRK SCCP subsystem 

The INTERWRK SCCP subsystem provides connection free signaling for 
TCAP messages between the CCS7 and PRI signaling links. All TCAP 
messages received by the INTERWRK SCCP subsystem have been sent over 
CCS7 links. To support the routing of a CCS7 network, a nonstandard GTT 
structure has been developed. This GTT structure contains the facility 
identifier and network identifier. 


The entry in table MSGRTE is based on the network name and destination 
digits. The TCAP messages contain the destination DN and its corresponding 
network name. 


Every TCAP message the INTERWRK SCCP subsystem receives has a 
facility ID. The facility ID identifies what feature is related to the TCAP 
message. The feature can be one of the following: 


e ACD 
e RAG 
e MWT 


DMS-100 Family MDC SMDI Setup and Operation SN04 and up 


9-40 SMDI:features 
AJ1538 - Message Waiting Indicator - PRI (continued) 


TCAP incoming to INTERWRK SCCP subsystem 


table MSGRTE 


CCS7 


Local 


Message waiting 


CCS7 INTERWRK 
SCCP subsystem 


SCCP NMS subsystem 

All TCAP messages received by the NMS subsystem have been sent over 
CCS7 links. The subsystem only receives messages for NMS. Any messages 
received by a SCCP NMS subsystem terminate locally regardless of the value 
of the NMSTBRTE option in NETNAMES. 


Note: The Message Waiting Indicator - PRI feature does not change the 
way the SCCP NMS subsystem receives messages. 


TCAP incoming to the SCCP NMS subsystem 


SCCP 
NMS 


CCS7 


subsystem 


Switch B 
Network MWI 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


Network MWI example 
In this example, the SMDI switch A (ESN 393) records a message for a client 
on switch C. A network MWI activation request is sent to a user on switch B 
(ESN 395). Table MSGRTE on switch B queries a TCAP message to initiate a 
leave message request for a DN on switch C. This message is sent as a PRI 
facility message to the PRI D-channel associated with trunk group 
K2KDTI64CLLP1. When the PRI facility process on switch C receives this 
message, the TCAP message is removed from the PRI facility message. The 
TCAP message is decoded, and the MWI is activated. Switch C sends a 
response TCAP message to switch B over the PRI D-channel. Switch B routes 
the response TCAP message over the CCS7 signaling link associated with 
trunk group NCSUSWITCHAPC. 


Network MWI example 


NWI indicator TCAP 


Switch A Switch B Switch C 
(SMDI) (tandem) (client) 


ESN 393 ESN 395 ESN 397 
DMS-100 DMS-100 DMS-100 


Response TCAP Response TCAP 


Recorded message 
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Datafill at switch A 


Datafill example for table MSGRTE 


Example of a MAP display: 


MSGRTKEY MSGRTRES 


NCSU 397 397 

( SS7 NCSUSWITCHAPC 0 N $)$ 
NCSU 393 393 

( LOCAL 3 N)$ 


Datafill at switch B 


Datafill example for table MSGRTE 


Example of a MAP display: 
MSGRTKEY MSGRTRES 


NCSU 397 397 
( PRA K2KDT164CLLP1 0 N )$ 


NCSU 393 393 
( SS7 NCSUSWITCHAPC 0 N $)$ 


Datafill at switch C 


Datafill example for table MSGRTE 


Example of a MAP display: 


MSGRTKEY MSGRTRES 


NCSU 397 397 
( PRA K2KDT164CLLP1 0 N )$ 


NCSU 393 393 
( LOCAL 3 N)$ 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


Activation/deactivation by the end—user 


The Message Waiting Indicator - PRI feature requires no activation or 
deactivation by the end user. 


Limitations and restrictions 


Limitations and restrictions of the Message Waiting Indicator - PRI feature 
include the following: 


SMDIs that are datafilled in table SLLNKDEV with the NUMOFDIGS 
option set to ten digits can convert a seven—digit DN to a ten—digit DN 
outside the NPA of the SMDI. Therefore, such an SMDI can activate and 
deactivate a message waiting indicator of a subscriber residing outside the 
NPA of the SMDI. However, SMDIs that are datafilled in table 
SLLNKDEV with the NUMOFDIGS option set to 7 can convert a 
seven—digit DN to a ten—digit DN by assigning the NPA of the SMDI to the 
DN. Thus, the SMDI can activate a message waiting indicator of a 
subscriber residing inside the NPA of the SMDI. 


CRR will not remove the message from the SMDI. For example, if a user 
redials Meridian mail, the MWI lamp goes out. However, the voice 
message will not disappear unless it is deleted. 


Security codes are not screened on the server node when a subscriber's 
MWl is turned on; therefore, an unauthorized user could activate a 
message waiting indicator. However, security codes are screened when a 
subscriber's MWI is turned off, thereby eliminating the risk of an 
unauthorized network message service deactivating message waiting 
indicators and deleting subscribers’ messages. 


This feature does not direct message waiting tone notification to a remote 
phone. The message waiting tone and network MWI features are separate. 


Network MWI does not know the network name of the destination DN. 
The destination DN will be sent as PUBLIC. 


TCAP messages received by the NMS subsystem will route no further 
regardless of the value of the NMUSTBRTE option in NETNAMES. 


If a switch with the NMSTBRTE option routes a message to a switch 
without this option, it may not be possible to send a response message 
back. The first switch would assume, after the response timeout, that the 
feature activation has been unsuccessful. 
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Feature interactions 
The following features interact with the Message Waiting Indicator - PRI 
feature: 
e NMS 


e TCAP messages no longer have to be routed by the SCCP NMS subsystem 
over a pure CCS7 network. Now TCAP messages can be sent over a PRI 
by being routed through table MSGRTE. 


e CCS7/PRI—CCS7 and PRI interworking is supported. 

e Network executive message waiting 

e network executive message waiting (network EMW) uses table MSGRTE 
if the option is defined in table NETNAMES. 

e Network RAG , NACD , and network MWI 


e network RAG, network ACD, and network MWI use table MSGRTE, the 
PRI facility process, and the INTERWRK subsystem. Entries in table 
MSGRTE are not feature dependent. Tuples existing in this table are used 
when the NMSTBRTE option is enabled. Changes to this table affect 
network RAG, network ACD, and network MWI. 


Note: All restrictions for the Message Service-Network Message Waiting 
Indicator feature, AG1638, also affect the Message Waiting Indicator - PRI 
feature. 


Office parameters 
The Message Waiting Indicator - PRI feature does not affect office parameters. 


Datafill sequence 


The table NETNAMES is affected by the Message Waiting Indicator - PRI 
feature. 


Data tables required for Message Waiting Indicator - PRI 


Table 
NETNAMES 
MSGRTE 


Datafill procedure for table NETNAMES 


The following procedure shows the datafill for table NETNAMES. Table 
NETNAMES along with table NCOS and table IBNXLA allows the operating 
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AJ1538 - Message Waiting Indicator - PRI (continued) 


company to datafill station information against a DN on a logical network 
basis. This procedure contains only those fields that apply to Message Waiting 
Indicator - PRI. Refer to the Translations Guide for a description of the other 


fields. 


A new option, NMSTBRTE, has been added to table NETNAMES. This 
option was created to route TCAP messages by table MSGRTE. If the 
NMSTBRTE option is not defined, the old method of routing TCAP messages 
through the SCCP NMS subsystem will be used. 


Datafill for table NETNAMES 


Field Subfield 
NETNAME 
EXTNETID 
NETDIGS 
NETOPTS 
OPTION 


Explanation and action 
Enter the 1— to 32—character SCCP logical network name. 


This field defines the external network identifier, which is used 
externally to identify logical networks. Valid entries are from 1 to 
32 600. 


This field defines the value used to extract the correct number of 
digits from the stored DN. Enter a value that represents the 
number of digits in the logical network. Valid entries are from 0 to 
10. 


This field contains the following subfields: OPTION, EXTERNAL, 
INTERNAL, and NMXCHG. The Message Waiting Indicator - 
PRI feature affects only subfield OPTION. 


Enter NUSTBRTE to route the TCAP message to MSGRTE. 


Datafill example for NETNAMES 
The following example shows sample datafill for table NETNAMES. 


Datafill example for table NETNAMES 


Example of a MAP display: 


NETNAME 


EXTN 


ETID NETDIGS NETOPTS 


NCSU 0 


0 


( NMSTBRTE )$ 


Datafilling table MSGRTE 


Table MSGRTE provides the facility for routing networking features on PRI 
trunks. This table is the base for future networking development over PRI. 
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The proper network and digits must be specified before a message can be 
routed. See the Translations Guide for more information. 


Operational measurements 


The Message Waiting Indicator - PRI feature does not affect operational 
measurements. 


Logs 

The Message Waiting Indicator - PRI feature does not affect logs. 
Billing 

The Message Waiting Indicator - PRI feature does not affect billing. 


Service orders 
The Message Waiting Indicator - PRI feature does not affect service orders. 
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Flexible Line Delivery on SMDI 


AF6300 


NTXNO7AB 


DMSCCM06 and up 


Feature package prerequisites 


Description 


The Flexible Line Delivery on SMDI feature requires the following feature 
packages: 


Feature package prerequisites 

Feature package Feature package name 

NTXOO0AA Bilge 

NTX001AA Common Basic 

NTX730AA Multilink ASCII Device Driver 

NTX732AA Simplified Message Desk Interface (SMDI) 
NTX901AA Local Features | 


The Flexible Line Delivery on SMDI feature gives the SMDI Calling Number 
Delivery (SMDICND) option the ability to deliver, block, or perform 
intra—group comparison to determine the delivery of a calling directory 
number (DN) to a Simplified Message Desk Interface (SMDI). The 
SMDICND option's parameters can be datafilled independently for RES and 
IBN agents and direct and indirect call types. The SMDICND option will 
always deliver the forward—from DN, even if an intra—group check fails. 


On direct calls to SMDI from RES and IBN agents, the SMDICND option 
performs intra-group comparison between the calling party's customer group 
and SMDI agent's customer group to determine if the calling DN should be 
delivered. For indirect calls, the intra-group comparison can be made between 
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AF6300 - Flexible Line Delivery on SMDI (continued) 


the calling party and the forward—from party or between both calling and 
forward—from parties and the SMDI agent. If the intra-group comparison fails, 
the calling DN is not delivered. 


Background information 


An SMDI provides a central answering service by integrating call forwarding 
and message waiting. An SMDI consists of a group of lines (a hunt group or 
uniform call distribution [UCD] group) and a dedicated datalink interface that 
provide the delivery of incoming call information to a voice mail system. The 
incoming information includes the calling party number, the forward—from 

party number, and the type of call forwarding involved: Call Forwarding Busy 
(CFB), Call Forwarding Don't Answer (CFD), or Call Forwarding All (CFW). 
See the following figure for an example of SMDI incoming call information. 
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AF6300 - Flexible Line Delivery on SMDI (continued) 


SMDI incoming call information 


DMS-100 


CFD, CFB, or CFU to 
main UCD or hunt number 


UCD or hunt group 


Voice lines 


al SMDI datalink 


1x67 or 1x89 


Message format: MDaaabbbifffffff coccccc 


Where: aaa = message desk number (001 --063) 
bbbb = message desk terminal (0001 -- 2047) 
fffffff = forward-from station DN 
ccccccc = calling station DN 


i = type of call forwarding 
A = forward all calls 
B = forward busy calls 
N = forward no answer calls 
D = direct calls 


Operation 
The SMDICND option provides the ability to block, deliver, or perform 
intra-group checking to compare the calling DN to SMDI independently for 
RES and IBN agents and direct and indirect call scenarios. A direct call is an 
incoming call in which a user has directly dialed the hunt group DN or UCD 
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AF6300 - Flexible Line Delivery on SMDI (continued) 


group DN for the purpose of message retrieval. An indirect call is an incoming 
call that has been forwarded to SMDI for the purpose of message deposit. The 
intra-group checking compares the agents involved to see if they are in the 
same customer group. If the agents being compared are not in the same 
customer group, the calling DNs are not delivered. 


The SMDICND option has the following parameters for determining delivery 
of the calling DN: 


e CGN_FOR_RES_DIRECT 
e CGN_FOR_RES_INDIRECT 
e CGN_FOR_IBN_DIRECT 
e CGN_FOR_IBN_INDIRECT 


Indirect calls can use the following delivery options: Block, Deliver, 
Compare_CG, or Compare_CG_ALL. Direct calls use only these delivery 
options: Block, Deliver, Compare_CG. 


Option Compare_CG compares the customer group information of the calling 
party and the SMDI agent for direct calls and the calling party and the 
forward—from party for indirect calls. If the intra-group comparison fails, the 
calling DN is not delivered. 


Option Compare_CG_ALL compares the customer group information of the 
calling party, the forward—from party, and the SMDI agent for indirect calls 
only. If the intra-group comparison fails, the calling DN is not delivered. 


POTS lines are handled differently from RES and MDC lines. The SMDICND 
option will not deliver the calling DN on a direct call from a POTS agent. For 
indirect calls, the calling DN is not delivered if the forward—from party is a 
POTS agent, but the forward—from DN is delivered. 


Intra—group determination 
There are four ways to obtain the customer group information for intra-group 
determination. These are line agent status, multi—location business group 
(MBG) parameter, NETINFO parameter, and table TRKGRP static customer 
group. The line agent status is applicable to line calls while the MBG 
parameter, NETINFO parameter, and TRKGRP static customer group are 
applicable to trunk calls. 


Intra—group checking using line agent status 

The criteria used to determine if the agents are intra—group is the customer 
group information of the agent itself. Agents within the same customer family 
are considered to be in the same customer group. A customer group family is 
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created by uniting different customer groups as a customer family using table 
CUSTFAM. The way in which the call is translated does not influence the 
intra-group checking. 


Intra-group checking using MBG parameter 

An MBG call is an MDC customer-originated call that routes over a public 
common channel signaling 7 (CCS7) facility, but retains the identity of the 
associated originator's customer group. This is accomplished through the 
business group parameter in the initial address message (IAM). For a call to be 
considered an MBG call, it must not reach the public facility by means of a 
NET DOD access code in table IBNXLA. 


In a POTS ISDN user part (ISUP) call to an SMDI, or to a line that is forwarded 
to an SMDI, the intra-group determination is accomplished using the MBG 
parameter. If the business group parameter is present in the ISUP IAM, this 
call may be an intra—group call, even if it is on a public facility. If the business 
group parameter is present, it is mapped to an entry in table BGDATA. If the 
entry in table BGDATA corresponding to the information passed in the IAM 
has the CUSTGRP option, and if the name of the customer group is the same 
as the customer group for the other agents needed to make this an intra—group 
call, then the DN is delivered to the SMDI. 


Intra—group checking using NETINFO parameter 

IBN ISUP trunks provide the capability to allow IBN trunks, specifically 
IBNTO, IBNTI, and IBNT2, to use ISUP signaling. This capability combines 
the advantages of IBN trunks with the functionality of ISUP trunks. In regard 
to SMDI, the advantage of this is the ability to know the calling and 
forward—from party information from the ISUP functionality as well as the 
customer group information from the IBN functionality. The customer group 
of the originating agent is extracted from the NETINFO parameter contained 
in the IAM. The IAM is the first message sent on the ISUP against each other 
network for an ISUP call. If this customer group is the same as that of the other 
agent used in the intra-group comparison, the calling DN is delivered to 
SMDL. If both the business group parameter and the NETINFO parameter exist 
in the IAM, the business group parameter takes precedence over the NETINFO 
parameter. 


Intra—group checking using table TRKGRP static customer group 
If neither the BG or NETINFO parameters are contained in the IAM, the static 
customer group from table TRKGRP is used to determine the customer group. 
If the static customer group is the same as that of the other agent used in the 
intra-group comparison, the calling DN is delivered to SMDI. 
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Activation/deactivation by the end—user 
End-users forward their phones to the SMDI by activating call forwarding on 


either a Meridian business set (MBS) or a 2500 set and dialing the SMDI 
directory number. 


Limitations and restrictions 


The Flexible Line Delivery on SMDI feature has the following limitations and 
restrictions. 


e When using IBN ISUP trunking, and both the NETINFO and the business 
group (BG) parameters are passed in the IAM, the BG parameter takes 
precedence to determine the customer group. 


e On any call in which the forwarding party resides in a different office than 
the SMDI, the calling DN is blocked by SMDICND. This applies also to 
call forward chain scenarios, in that if any leg routes via a trunk, the calling 
DN is blocked by SMDICND. 


e All non-IBN type trunks are treated as POTS agents by this feature in that 
the calling DN is blocked and the forward—from DN is delivered if it is 
available. 


e If it is not possible to determine the customer group of an agent involved 
in a call, the call is not considered intra—group. 


e The SMDICND option is not compatible with BNN, CPU, MPH, or PRH 
type hunt groups and is not assignable through SERVORD to MBS hunt 
group agents. 


Feature interactions 


The following paragraphs describe the interactions between Flexible Line 
Delivery on SMDI and other functionalities. 


Virtual Facility Group 
The customer group associated with a Virtual Facility Group (VFG) that has 
been spanned within a call will not be recognized by the intra—group 
determination process. This feature uses the customer group associated with 
the actual physical call processing agent to determine the customer group 
appearance. The only exception to this is an ISUP origination which includes 
MBG or NETINFO parameters. 


LASTFWDN option 
If the LASTFWDN option in table SLLNKDEV is assigned to the SMDI 
datalink, the LASTFWDN option has precedence in determining the identity 


of the forward—from party used in any customer group comparison initiated by 
the SMDICND option. 
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Office parameters 
The Flexible Line Delivery on SMDI feature does not affect office parameters. 


Datafill sequence 
The following tables affect the Flexible Line Delivery on SMDI feature: 


Data tables required for Flexible Line Delivery on SMDI 


Table 


UCDGRP 


HUNTGRP 


Datafill procedure for table UCDGRP 
The following procedure identifies the datafill for table UCDGRP. This 
procedure contains only those fields that apply to Flexible Line Delivery on 
SMDI. Refer to the7ranslations Guide for a description of other fields. 


Datafilling table UCDGRP 


Field Subfield Explanation and action 


OPTIONS Enter SMDICND for SMDI calling number delivery. 
If SMDICND is entered, the following subfields are presented. 


CGN_FOR_ Calling number for RES direct. Specifies delivery of the calling 
RES_ DIRECT party information given a direct call to SMDI from a RES agent. 
The possible entries are block, deliver, or compare_CG. 


CGN_FOR_ Calling number for RES indirect. Specifies delivery of the 
RES _ calling party information given an indirect call to SMDI when the 
INDIRECT SMDI subscriber (forward—from party) is a RES agent. The 


possible entries are block, deliver, or compare_CG, or 
compare_CG_ALL. 


CGN_FOR_IBN Calling number for IBN direct. Specifies delivery of the calling 
_DIRECT party information given a direct call to SMDI from a IBN agent. 
The possible entries are block, deliver, or compare_CG. 


CGN_FOR_IBN Calling number for IBN indirect. Specifies delivery of the calling 

_INDIRECT party information given an indirect call to SMDI when the SMDI 
subscriber (forward—from party) is a IBN agent. The possible 
entries are block, deliver, or compare_CG, or 
compare_CG_ALL. 
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Datafill example for table UCDGRP 
The following shows example datafill from table UCDGRP. 


Datafill example for table UCDGRP 
Example of a MAP display: 


UCDNAME ACD CUSTGRP UCDRNGTH THROUTE NSROUTE 
PRIOPRO MAXPOS DBG DEFPRIO RLSCNT MAXWAIT MAXCQSIZ OPTIONS 


SMDI11 N BNR O OFRT 1 OFRT 1 12 12 N 0 0 1200 12 
(UCD_SMDI SMDI1 1 $) (SMDICND COMPARE_CG BLOCK DELIVER 
COMPARE_CG_ALL) $ 


Datafill procedure for table HUNTGRP 


The following procedure identifies the datafill for table HUNTGRP. This 
procedure contains only those fields that apply to Flexible Line Delivery on 
SMDI. Refer to the7ranslations Guide for a description of other fields. 


Note: The preferred method of assigning the SMDICND option to a hunt 
group is through SERVORD. 


Datafilling table HUNTGRP 


Field Subfield Explanation and action 


OPTIONS Enter SMDICND for SMDI calling number delivery. 
If SMDICND is entered, the following subfields are presented. 


CGN_FOR_ Calling number for RES direct. Specifies delivery of the calling 
RES_ DIRECT party information given a direct call to SMDI from a RES agent. 
The possible entries are block, deliver, or compare_CG. 


CGN_FOR_ Calling number for RES indirect. Specifies delivery of the 
RES _ calling party information given an indirect call to SMDI when the 
INDIRECT SMDI subscriber (forward—from party) is a RES agent. The 


possible entries are block, deliver, compare_CG, or 
compare_CG_ALL. 
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Datafilling table HUNTGRP 


Field Subfield Explanation and action 


CGN_FOR_IBN Calling number for IBN direct. Specifies delivery of the calling 
_DIRECT party information given a direct call to SMDI from a IBN agent. 
The possible entries are block, deliver, or compare_CG. 


CGN_FOR_IBN Calling number for IBN indirect. Specifies delivery of the calling 

_INDIRECT party information given an indirect call to SMDI when the SMDI 
subscriber (forward—from party) is a IBN agent. The possible 
entries are block, deliver, compare_CG, or compare _CG_ALL. 


Datafill example for table HUNTGRP 
The following shows example datafill from table HUNTGRP. 


Datafill example for table HUNTGRP 
Example of a MAP display: 
HTGRP SNPA DN GRPTYP GRPDATA 


1 619 6751234 DNH N N N RCVD N N N N N N 10 (SMDI 63 
SMDI1) (SMDICND COMPARE_CG BLOCK DELIVER COMPARE_CG_ALL) $ 


Operational measurements 


The Flexible Line Delivery on SMDI feature does not affect operational 
measurements. 


Log reports 
The Flexible Line Delivery on SMDI feature does not affect logs. 


Billing 
The Flexible Line Delivery on SMDI feature does not affect billing. 


Service orders 
SERVORD can be used to add or delete option SMDICND to or from a hunt 
group line. This option is compatible with hunt group types Multi—Position 
Hunt (MPH), Directory Number Hunt (DNH), and Distributed Line Hunt 
(DLH). This option is only compatible with RES and IBN hunt groups. The 
SMDI option must be present to assign the SMDICND option to a hunt group. 
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Service order limitations and restrictions 
SMDICND is not compatible with the following options: 


e AAK (Automatic Answer Key) 

e ACD (Automatic Call Distribution) 

e AUL (Automatic Line) 

e BC (Basic Call) 

e BNN (Bridged Night Number) 

e CAG (Call Agent) 

e CLSUP (Call Supervisor) 

e CNAB (Calling Name Delivery Blocking) 
e CNDB (Calling Number Delivery Blocking) 
e CPU (Call Pickup) 

e DTM (Denied Termination) 

e EHLD (EKTS Hold) 

e KSH (Key Short Hunt) 

e MDN (Multiple Appearance Directory Number) 
e MLAMP (MDN Lamp) 

e MPH (Multiple Position Hunt) 

e MREL (MDN Release) 

e PREMTBL 

e PRH (Preferential Hunting) 

e RMB (Random Make Busy) 

e SCMP (Series Completion) 

e SHU (Stop Hunt) 

e SLQ (Single—line Queuing) 


The SMDICND option is not assignable to an MBS through SERVORD. 


297-2051-104 Preliminary 13.01 September 2004 


SMDl:features 9-57 


AF6300 - Flexible Line Delivery on SMDI (continued) 


Service order prompts 


The following table shows the service order prompts used to assign the 
Flexible Line Delivery on SMDI feature to a hunt group line. 


Service order prompts for Flexible Line Delivery on SMDI 


Prompt 


SONUMBER 


Valid input 


numeric 


Explanation 


The unique number of the service order to 


DN_OR_LEN 


OPTION 


CGN_FOR_RES_D 
IRECT 


CGN_FOR_RI 
NDIRECT 


Gl 
Nn 
H 


CGN_FOR_IBN_D 
IRECT 


CGN_FOR_IBN_I 
NDIRECT 


numeric 


SMDICND 


block, 
deliver, 
compare_CG 


block, 
deliver, 
compare_CG, 
compare_CG_ALL 


block, 
deliver, 
compare_CG 


block, 
deliver, 
compare_CG, 
compare_CG_ALL 


be entered. 


Enter the line's DN or LEN. In the case of 
MLH, DLH, or DNH hunt members, if a DN is 
specified, then the user is prompted for 
the LEN. If the LEN is entered, then the 
user is not prompted for the DN. 


Option(s) associated with a service to be 
established, modified, or deleted. A 
maximum of 20 options can be specified in 
any single ADD, ADO, EST, or NEW command. 
Enter SMDICND. 


Specifies delivery of the calling party 
information given a direct call to SMDI 
from a RES agent. 


Specifies delivery of the calling party 
information given an indirect call to SMDI 
when the SMDI subscriber (forward-from 
party) is a RES agent. 


Specifies delivery of the calling party 
information given a direct call to SMDI 
from a IBN agent. 


Specifies delivery of the calling party 
information given an indirect call to SMDI 
when the SMDI subscriber (forward-from 
party) 


is a IBN agent. 
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Example service orders for implementing Flexible Line Delivery on SMDI 
The following example shows a new hunt group line option, SMDICND, being 
added to an existing line using the ADO command. 


Setting up SMDICND using ADO 


Input and response 


Input in Prompt mode 


> SERVORD 

SO: 

> ADO 

SONUMBER: NOW 92 7 9 AM 
> 
DN_OR_LEN: 

> 6754000 

OPTION: 

> SMDICND 
CGN_FOR_RES_DIRECT: 

> COMPARE_CG 
CGN_FOR_RES_INDIRECT: 
> BLOCK 
CGN_FOR_IBN_DIRECT: 
> DELIVER 
CGN_FOR_IBN_INDIRECT: 
> COMPARE _CG_ALL 
OPTION: 

>$ 


Input in No—prompt mode 


> ADO $ 6754000 (SMDICND COMPARE_CG BLOCK DELIVER 
COMPARE_CG_ALL) $ 


297-2051-104 Preliminary 13.01 September 2004 


Name 


Number 


Packages 


BCS 


SMDI:features 9-59 


AF5725 - RES High Speed SMDI 


RES High Speed SMDI 


Note: This feature is not available for CS 2000 - Compact offices. 


AF5725 


NTX732AA and NTXNIOAA 


DMSCCM013 


Feature package prerequisites 


Description 


The RES High Speed SMDI feature requires the following feature packages: 


Feature package prerequisites 

Feature package Feature package name 

NTXOO0AA Bilge 

NTX001AA Common Basic 

NTX100AA Integrated Business Networks - Basic (IBN) 
NTX730AA Multilink ASCII Device Driver 

NTX732AA Simplified Message Desk Interface (SMDI) 
NTX901AA Local Features | 

NTXN10AA High-Speed SMDI 


RES High Speed SMDI introduces a method of determining the call request 
retrieval (CRR) or Message Waiting (MWT) dial—back desk for local 
subscribers (on the host node) and external subscribers (outside the host node), 
eliminating the need for a default message desk. 


In addition, RES High Speed SMDI modifies the removal of message waiting 
indicators (MWI) that were set at the message center for subscribers in a local 
configuration. 
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Background information 


Operation 


Each message desk is provided with a primary directory number (PDN) that is 
associated with a set of uniform call distribution (UCD) or hunt lines. 
Formerly, the Simplified Message Desk Interface (SMDI) application selected 
one message desk as the only CRR access for each data link. For data links 
with only one message desk, the directory number (DN) associated with that 
desk served as the message waiting requestor. However, for data links with two 
or more message desks in service, SMDI was unable to determine which desk 
was the designated primary desk (based solely on the incoming data). 
Therefore, SMDI always assigned message desk 63 as the CRR route access 
to the voice messaging system (VMS). 


Before this feature, the method of defaulting to message desk 63 contributed 
unnecessary engineering requirements into SMDI. External subscribers 
(located outside the host node) needed to use a common message desk during 
CRR to a message center. 


If message desk 63 was assigned as the only CRR access, the following 
problems developed: 


e Some message centers could not support multiple message desks with the 
same desk number (that is, message desk 63). 


e The voice links associated with message desk 63 became overloaded 
during high traffic. 


e Message desk 63 could be overbilled. 


Also, SMDI failed to remove an MWI after changes to the PDN of a message 
desk. The MWI would remain stuck in the ON state. 


RES High Speed SMDI modifies the MWI setting and removal functional 
areas against nodal and network subscribers by eliminating the need for default 
message desk 63. This method enables CRR routing to be executed through the 
subscriber's primary desk (nodal) or a common desk (nodal or network) other 
than message desk 63. 


For network cases, option COMMON is introduced in table SLLNKDEV 
(Link Device Table) to enable telephone operating company personnel to 
select a common message desk other than message desk 63 for each SMDI link 
to be used during message retrievals. 


If an entry for option COMMON is not in table SLLNKDEY, host subscribers 
must use their primary message desk, and external subscribers must use the 
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first message desk. Network MWI requests on links without option 
COMMON generate an SMDI105 log. 


The following figure shows a simple VMS configuration. 
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AF5725 - RES High Speed SMDI (continued) 


Simple VMS configuration 


Local customerpremises 


dae 
i Subscriber 
* stations 


VMS 


External customer 
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, Subscriber 
» stations 


DMS-100 host node 


Message desks 
UCD 1-999 / HUNT 1-63 


Data link (0--63) 


ISUP/PRI 


Remotenode 
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Nodal or host calls 


Nodal or host calls are located on the host switch where the VMS and SMDI 
application are located. 


RES High Speed SMDI provides local VMS subscribers CRR access to the 
message center through a (primary) message desk other than COMMON 
message desk. 


The following figure depicts a typical MWI request (either setting or removal) 
data flow for a local (nodal) subscriber. 


Nodal MWI request scenario 


DMS-100 host node 


SMDI data link 


Incoming messages: 
OP:MWI 3625555! 
(MWI setting) 
RMV:MWI 3625555! 
(MWI removal) 


SMDI 


LN 


MWI “on” or “off” request 


Local subscriber 
(362-5555) 
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AF5725 - RES High Speed SMDI (continued) 


The following table lists MWI request results for all possible nodal 


configurations. 


MWI requests for nodal configurations 


Number of 
desks Option COMMON 
1 desk No Option 


Option COMMON available (ALL 
or NETWORK) 


2 or more desks | No option COMMON or option 
message desks | COMMON with CRR type 
NETWORK 


Option COMMON with CRR type 
ALL 


MWI requests 


The message desk is used for MWI settings. 
The new MWT data block is not used. 


Removals are executed by the nodal MWI 
removal implementation. 


This option is not necessary because there is 
only one desk. 


The nodal MWI setting (MWT data block) uses 
the primary desk. 


If a primary desk is not found during MWI 
setting, a rotational desk is used. MWIls do not 
"stick" due to nodal removal implementation. 


The MWI setting uses a rotational desk. 


MWIs do not "stick" due to nodal removal 
implementation. 


SMDI enhancements on nodal MWI settings and removals 
This feature modifies the nodal MWI removal process, whereby MWI are 


removed. 


To eliminate the need of a default desk for local subscribers, some MWT 
modifications are required. The MWT supplemental data block contains 
information about an agent's MWT. 


RES High Speed SMDI expands the MWT data block to include an SMDI link 
number (0 to 63) and a message desk number (1 to 999) for nodal MWI 
settings. If option COMMON is datafilled in table SELNKDEV with CRR 
type ALL set, this data block is not used. Network MWI requests do not use 


this enhancement. 


The area inside the MWT data block is filled during call processing (for local 
subscribers) and is transparent to the subscriber and telephone operating 


company personnel. 


In addition, when the message desk PDN is changed or deleted, SMDI can fail 
to remove MWT requestors against local telephone sets with MWIs turned on 
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prior to the change. This results in the MWIs being stuck in the on state until 
maintenance personnel dequeues all the requestors. 


RES High Speed SMDI enhances the MWI (set by SMDI) removal on local 
subscribers only by dequeuing requestors based on their call processing 
identifiers (CPID) instead of their DNs. 


Network or external calls 
Network or external calls are located outside the host switch. Network 
message service (NMS) uses the signaling system 7 (SS7) protocol to access 
the MWI capability. This enables a message service on one node to activate 
and deactivate the MWI for a subscriber on a different node (provided the two 
nodes support transaction capability application part [TCAP] 
communication). The two nodes must have either ISDN user part (SUP) or 
primary rate interface (PRI), or both, in order to support NMS. 


Network subscribers must always use a common desk for CRR access.The 
option COMMON in the table SLLNKDEV can be used to select a common 
message desk on an individual data link basis. Once a common desk is defined, 
it is used during all network MWI requests (settings and removals) for 
subscribers of the link. When datafilling this option, the desk number is 
specified. Also datafilled is whether the specified message desk is to be used 
only by network subscribers or by both host and network subscribers. 


Host subscribers must always use their primary message desk during CRR. 


The following figure depicts a typical MWI request (either setting or removal) 
data flow for an external (network) subscriber. 


Network MWI request scenario 


MWI “on” or 
“off” request 


DMS-100 host node 


Remote node 


SMDI data link 


OP:MWI 362555! 

or RMV:MWI 
External 362555! 
subscriber VMS 
(362-5555) 
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AF5725 - RES High Speed SMDI (continued) 


The following table lists MWI request results for all possible network 
configurations. 


MWI requests for network configurations 


Number of 
desks Option COMMON MWI requests 


1 desk No option MWI settings and removals use the message 
desk. 


Option COMMON available (ALL | This option is not necessary because there is 
or NETWORK) only one desk. 


2ormore desks | No option COMMON MWI settings and removals use the first 
message desk. Log SMDI105 generates and 
appropriate action is taken. 


Option COMMON with CRR type | MWI settings and removals use the common 
ALL or NETWORK available desk refinement DESKNUM defined with 
option COMMON. 


Activation/deactivation by the end—user 
RES High Speed SMDI requires no activation or deactivation by the end user. 


Limitations and restrictions 
The following limitations and restrictions apply to RES High Speed SMDI 


e Each telephone with option MWT can store information on only one 
SMDI link. Hence, subscribers belonging to more than one VMS may need 
to use a rotational message desk. 


e The nodal MWI setting implementation (MWT data block expansion) is 
only applicable to subscribers who are redirected to a VMS. The 
redirecting options supported by SMDI include Call Forwarding (CFW), 
Series Completion (SCMP), Line Overflow to DN (LOD), and Key Short 
Hunting (KSH). 


Note: Call Forwarding (CFW) takes precedence over Line Overflow to 
DN (LOD), when sending redirecting information to the VMS, if both 
occur on the same node. 


e Acommon message desk is always used for network MWI settings and 
removals. 


Feature interactions 
RES High Speed SMDI does not interact with any other features. 
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Office parameters 
RES High Speed SMDI does not affect office parameters. 


Datafill sequence 
Table SLLNKDEV is affected by RES High Speed SMDI. 


Data table required for SMDI Data Link Reengineering 


Table 


SLLNKDEV 


Datafill procedure for table SLLNKDEV 


The following procedure identifies the datafill for table SLLNKDEV. This 
procedure contains only those fields that apply to RES High Speed SMDI. 


Datafill procedure for table SLLNKDEV 


Field Subfield Explanation and action 

XFERS This field consists of subfield XFER. 
XFER Enter SMDIDATA as the transfer value. 
OPTION Enter COMMON to select a common message 


desk for each SMDI link to be used during CRR 
and datafill refinements DESKNUM and 
CRRTYPE. 


DESK_NUM This refinement indicates the number of the 
common message desk used by subscribers 
when accessing CRR. Enter a value from 1 to 
999. 


CRRTYPE This refinement specifies the type of CRR that 
uses the common message desk number. 
Enter ALL if all link subscribers (host and 
remote) are to use the common message desk 
during CRR. Enter NETWORK if only 
subscribers outside the host node are to use 
the common message desk during CRR. 
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Datafill example for table SLLNKDEV 
The following example shows sample datafill from table SLLNKDEV. Option 
COMMON is assigned to device names VMAILI and VMAIL2. 


Datafill example for table SLLNKDEV 


Example of a MAP display: 


DEVNAME DEVTYPE XLATION PROTOCOL DRECTION 
XFERS 


VMAIL11X89 3 2NONE NONEINOUTLK 
(SMDIDATA $) (COMMON 2 NETWORK $) $ 


VMAIL21X89 4 2NONE NONEINOUTLK 
(SMDIDATA (NUMOFDIGS 10) (COMMON 
3 ALL) $ $ 


Operational measurements 
RES High Speed SMDI does not affect operational measurements. 


Log reports 
RES High Speed SMDI introduces logs SMDI104, SMDI105, and SMDI106. 


An SMDI104 log is generated to indicate that the switch failed to locate a 
primary message desk for a host requestee's line. Hence, a rotational message 
desk is used. (SMDI104 is an information—only log.) 


An SMDI105 log is generated when the switch failed to locate a common 
message desk for a network MWI request (setting or removal). The first 
message desk datafilled is used to set the MWI. Telephone operating company 
personnel must define a common message desk by configuring the link (using 
message desk 63 or datafilling option COMMON in table SELNKDEV). 


An SMDI106 log is generated when the switch failed to locate the message 
desk number associated with option COMMON in table SLLNKDEV. 
Telephone operating company personnel must define the message desk 
number to be associated with option COMMON in table SELNKDEYV, or 
delete the option if it is not needed. The message desk number is defined by 
datafilling table UCDGRP for UCD group members or table HUNTGRP for 
HUNT group members. 
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Billing 
RES High Speed SMDI does not affect billing. 


Service orders 
RES High Speed SMDI does not affect service orders. 
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AQ1245 - Remote Call Forwarding Enhancements 


Name 

Remote Call Forwarding Enhancements 
Number 

AQ1245 
Packages 

RES00020 


Sourced release 
NAOO1 


Feature package prerequisites 
The Remote Call Forwarding Enhancement feature requires the following 


feature packages: 


Feature package Feature package name 


NTX021AA Remote Call Forwarding (RCF) 


Description 
This enhancement to RCF passes the RCF number in the call forward data to 
the next signalling link for a remote call. This enhancement applies to call 
forwarding that involves either: 


e CCS7 ANSI ISDN User Part (ISUP) trunks 
e lines supported by a simplified message desk interface (SMDI) data link 


Background information 


The RCF Enhancements feature requires software optionality control (SOC) 
using SOC RESO00020. The enhancement passes the original called number 

(OCN) and the redirecting number (RGN) as the called data for ISUP trunks 
and the forwarding from number and the type of forwarding information as the 
called data for SMDI data links. 


To understand the RCF Enhancements feature, an originator (621-1234) dials 
an RCF number (777-1000) that forwards to a voice mail system with SMDI 
messaging. Without the RCF Enhancements feature, the originator’s DN 
(621-1234) passes on to the SMDI as the calling number (CGN). With the RCF 
Enhancements feature, the dialed RCF number (777-1000) passes on to the 
SMDI as the CGN. 
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AQ1245 - Remote Call Forwarding Enhancements (end) 


Operation 


A response of RCF to the DNTYPE prompt in SERVORD generates a 
SIGDATA prompt. A SIGDATA response of Y (yes), enables the RCF 
Enhancements feature. A response of N (no) disables the RCF Enhancements 
feature. Refer to the SERVORD section of this document for a detailed 
description for adding RCF to a DN. 


The SMDI link datafill in the SLLNKDEV table determines the SMDI 
forwarding from number. If the LASTFWDN option in the SELNKDEV table 
is datafilled, the SMDI sends the RCF DN as the called number if the RCF DN 
is either: 


e the last forwarding number in the call chain 

e the only called number in the call chain 

If the LASTFWDN option in the SELNKDEYV table is not datafilled, the SMDI 
sends the RCF DN as the called number if the RCF DN is either: 

e the first forwarding number in the call chain 


e the only called number in the call chain 
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59010576 - Messaging Services Functional Component Re-engineer 


Feature name 


Description 


Messaging Services Functional Component Re-engineer 


The Messaging Services Functional Component (FC) Re-engineer feature 
includes the present functionality or services that follow: 


e DMS-100 switch to remote system link for 1X67, HS1X67, and 1X89 
multiprotocol controller card (MPC) 


e DMS-100 switch to remote system link for SMDIDATA, SMDRRPT, 
ACDRPT, and MGTRPT software 


e Simplified Message Desk Interface (SMDIJ) software that supports 
Bellcore TR-TSY00283 


e Station Message Detail Recording (SMDR) reporting software 
e Message Waiting Indication (MWT) software 
e Executive Message Waiting (EMW) software 


e Network Message System (NMS) software for network MWT and network 
EMW 


e Call retrieval software (CRR or CAR) 
e Class Message Waiting Indication (CMWI) software 


The development of the FC software occurred approximately in Batch Change 
Supplement (BCS) 23. The expansion of the FC software with many different 
features continued for more than ten years. The software did not include 
generic functionality and interactions with other features. The FC software 
does not have a clear architectural design for future support, expansion, and 
generic service for other features 


The problems with the FC software require re-engineering to reduce service 
requests (SR) and provide manageable software. The FC re-engineering 
provides a service without major change. 
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59010576 - Messaging Services Functional Component Re-engineer 


The Messaging Services Functional Component Re-engineer feature adds the 
functionality and improvements that follow: 


development of IOM support for SL-100 Link (SLLNK) link 


robustness improvements in table SLLNKDEV (SL-100 Link Device) for 
datafill, warnings, and alarms 


real time improvement for Auxiliary Call Processing (AUXCP) usage. The 
real time improvement includes reduction of the SMDI link AUXCP 
allocation. The present AUXCP allocation is 6%. 


expansion of SMDI to support 999 message desks to meet Bellcore 
requirements. SMDI supports 63 message desks before this feature. 


conversion of software from North American (NA) directory number (DN) 
system format to E.164-Universal DN system format 


improvement in the usage of feature queue software resources (FTRQs) for 
MWT or EMW and removal of switch activity (SWACT) problems 


addition of the Message Waiting Lamp (MWL) display as the MWT 
indicator for the EMW option on a MBS when operating company 
personnel use the QLEN command 


changes to the key list check for EMW to occur at the Service Order 
System (SERVORD) level that now is done in table write procedures in the 
EMW software 


Hardware requirements 


The Messaging Services Functional Component Re-engineer feature has no 
new hardware requirements. 


Limitations and restrictions 


The limitations and restrictions that follow apply to the Messaging Services 
Functional Component Re-engineer feature: 


The entry in the DMS-100 switch must use two-digit message desk 
numbers if the voice mail system can only support two-digit message desk 
numbers. The DMS-100 switch does not check for assignment of message 
desk numbers in the voice mail system. 


The DMS-100 switch does not convert three-digit message desk numbers. 
The DMS-100 switch sends three-digit message desk numbers to the voice 
mail system. SMDI pads zero as prefix digit for single or two-digit 
message desk numbers. 
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59010576 - Messaging Services Functional Component Re-engineer 


Interactions 


The Messaging Services Functional Component Re-engineer feature supports 
existing interactions with other functionalities. 


Datafill 


The list that follows includes the Messaging Services Functional Component 
Re-engineer feature data schema tables: 


e Table SLLNKDEV 
e Table UCDGRP 


The Messaging Services Functional Component Re-engineer feature does not 
affect office parameters. 


Service orders 


The Messaging Services Functional Component Re-engineer feature does not 
add new commands or features to the Service Order System (SERVORD). The 
Messaging Services Functional Component Re-engineer feature allows an 
error message in SERVORD when the operating company personnel enters an 
invalid directory number list (DNLIST) for the EMW option. The error 
message applies to the NEW or CHF commands for the EMW option. 


Operational measurements 


The Messaging Services Functional Component Re-engineer feature does not 
change operational measurements (OM). 


Logs 
The Messaging Services Functional Component Re-engineer feature changes, 
updates, and adds logs. 


User interface 


The Messaging Services Functional Component Re-engineer feature does not 
change the user interface. 


Billing 
The Messaging Services Functional Component Re-engineer feature does not 
generate billing records or changes. 
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59037993 - SMDI over TCP/IP for CS 2000 - Compact 


Name 


Number 


Packages 


Simplified Message Desk Interface over Internet Protocol support for 
CS 2000 - Compact. 


59037993 


SMDIO001 


Sourced release 


SN04 


Feature package prerequisites 


Description 


This feature requires the following feature packages: 


Feature package prerequisites 


Feature package Feature package name 


NTXOO0AA Bilge 

NTX001AA Common Basic 

NTX100AA Integrated Business Networks - Basic (IBN) 
NTX101AA IBN - Enhanced Business Services 
NTX119AA IBN - Message Service 

NTX730AA Multilink ASCII Device Driver 

NTX901AA Local Features | 


Simplified Message Desk Interface (SMDI) is a set of features for customers 
of a central office (CO) which provides an interface to a Voice Mail 

System (VMS), Automated Attendant, or Text Messaging System (TMS). 
SMDI over TPC/IP integrates call forwarding, message waiting, and UCD 
with a TCP/IP datalink interface to a message desk system. 


The SMDI over TCP/IP feature requires software optionality control (SOC) 
using SOC SMDIO001. This feature enables a CS 2000 - Compact to interact 
with a VMS or TMS over an Ethernet link rather than an RS-232 link. 
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59037993 - SMDI over TCP/IP for CS 2000 - Compact (continued) 


This feature enables transmission of SMDI data in ASCII format over Ethernet 
since the CS 2000 - Compact does not offer serial hardware. Transmission 
over TCP/IP is accomplished by provisioning a TCP device in table 
SLLNKDEV. During provisioning, a prompt is made for the IP address and 
port number of the VMS or TMS. 


Hardware requirements 


If the VMS or TMS does not support Ethernet and must use an RS-232 link, a 
protocol adaptor device to convert the IP packets from the CS 2000 - Compact 
to the RS-232 line levels of the VMS or TMS is needed. 


Limitations and restrictions 


Interactions 


This feature supports CS 2000 - Compact offices only. The SMDR application 
is available on CS 2000 - Compact, but it is unsupported because billing 
records are sent to the CS 2000 Core Manager or the Core Billing Manager 
(CBM). SMDR over TPC/IP for SLLNK is not supported for 

CS 2000 - Compact offices. 


The TCP/IP link between the CS 2000 - Compact and the VMS or TMS is not 
carrier grade. If the VMS or TMS is assigned an IP address dynamically 
through DHCP, then the link will fail if the VMS or TMS is assigned an IP 
address that does not match the IP address provisioned in table SLLNKDEV. 


If the VMS or TMS has a single Ethernet link to the CS LAN, then 
communication between the CS 2000 - Compact and the VMS or TMS is lost 
during a CS LAN upgrade. The messages are not lost, but connectivity is 
interrupted during the reboot of the router that is connected to the VMS or 
TMS. 


The TCP/IP link cannot be set to OFFL since there is no hardware associated 
with the link. The TCP/IP link is managed through command at the SMDILNK 
MAP level. SMDIDISC is used to BSY the link, SMDICON is used to RTS the 
link. 


This feature interacts with the following SMDI features: 

e AG1638 - Message Service - Network Message Waiting Indicator 
e AG1980 - RES SMDI CLID Suppression 

e AF6300 - Flexible Line Delivery on SMDI 

e AQ1245 - Remote Call Forwarding Enhancements 
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The following features are not supported by this feature: 

e NC0009 - SMDI: Called DN Option and KSH Support 
e AJ1538 - Message Waiting Indicator - PRI 

e AF5725 - RES High Speed SMDI 


Datafill 


This feature requires datafilling a DEVTYPE of TCP in table SLLNKDEV. 
The IP address and port number of the VMS or TMS are required for subfields 
REM_SMDR_IP_ADDR and PORT_NO. 


Service orders 


This feature does not add new commands or features to the Service Orders 
System (SERVORD). 


Operational measurements 


This feature does not add new operational measurements (OM). The following 
are OMs pegged for the TCP/IP link. 


SLLNK provides measurements for the outgoing datalink utilities pertaining 
to SMDI data communication: 


e SLLNKOVE - number of messages being thrown away or overwritten in 
an attempt to enter a queue on a full queue 


e SLLNKOK - number of messages queue successfully to go across link 

e SLLNKQU - usage count of the number of messages in a queue waiting to 
be processed, updating every 100 secs 

SLLNKINC provides measurements for the incoming datalink utilities 

pertaining to SMDI data communication: 


e SLLNKIOV - number of messages that are overwritten or thrown away in 
an attempt to enter the queue on a full incoming queue 


e SLLNKIOK - number of messages queued successfully that will be 
received from the datalink 


e SLLNKIOF - this is the overflow register for SLLNKIOK 
e SLLNKIQU- number of messages in the queue waiting to be processed 


e SLLNKBAD- number of messages in the invalid format that are received 
from the datalink 
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59037993 - SMDI over TCP/IP for CS 2000 - Compact (end) 


Logs 


This feature does not create new log reports. However, the SMDI and SLNK 
log reports do report status for SMDI over TCP/IP links. 


User interface 


Commands at the SMDILNK MAP level are used to manage SMDI over 
TCP/IP links. 


Billing 


This feature does not generate billing records or changes. 
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List of terms 


ACD 
Automatic Call Distribution 


AMA 


automatic message accounting 


American Standard Code for Information Interchange (ASCII) 
A coded character set used for the interchange of information among 
information—processing systems, communications systems, and associated 
equipment. ASCII defines one format in which data is exchanged between 
an input/output device and the device controllers of the DMS—100 Family 
of switches. 


ASCII 


American Standard Code for Information Interchange 


ASCII device driver 
A generic interface between the DMS-—100 switch and the file system which 
interacts with various kinds of datalinks. 


Automatic Call Distribution (ACD) 
A set of Meridian Digital Centrex (MDC) features that assigns answering 
priorities to incoming calls and then queues and distributes the calls to a 
predetermined group of telephone sets designated as agent positions. 


automatic message accounting (AMA) 
An automatic recording system that documents all the necessary billing data 
of subscriber—dialed long distance calls. 


batch change supplement (BCS) 
A DMS-100 Family software release. 


BCS 


batch change supplement 
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caller 
Refers to the originator of an incoming call that is redirected to the message 
desk. 


call forwarding (CFW) 
A Meridian Digital Centrex (MDC) service that allows a subscriber to have 
incoming calls to a station's directory number (DN) forwarded to a 
predetermined DN. There are five types of call forwarding, as follows: 


e Call Forwarding Busy (CFB) permits all calls to a busy station to be 
forwarded to a designated station within the customer group. 


e Call Forwarding Don't Answer (CFD) permits an incoming call not 
answered within a specified length of time to be forwarded to another 
designated station. 


e Call Forwarding Fixed (CFF) permits stations to forward calls to 
locations determined by the operating company. 


e Call Forwarding Intragroup (CFI) permits stations to forward calls only 
to customer—defined locations within the customer group. 


e Call Forwarding Universal (CFU) permits stations to forward calls to 
locations inside or outside the customer group. 


Calling Number Blocking (CNB) 
An outgoing call service enabling a subscriber to block the display of the 
directory number (DN) information on the subscriber set of the person being 
called. 


Calling Number Delivery Blocking (CNDB) 
Custom Local Area Signaling Services (CLASS) software that blocks the 
display of the calling party's directory number (DN) on a Calling Number 
Delivery (CND) subscriber's set. 


Call Request (CAR) 
A line option assigned in table IBNFEAT which allows a user to activate call 
back. 


Call Request Activate (CRA) 
A feature activation code assigned in table IBNXLA which allows the user 
to activate call request. 


Call Request Delete All (CRDA) 
A feature activation code assigned in table IBNXLA to delete all call back 
requests to be retrieved. 
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Call Request Delete Specific (CRDS) 
A feature activation code assigned in table IBNXLA which allows the user 
to delete a specific request for call back. 


Call Request Retrieval (CRR) 
A feature activation code assigned in table IBNXLA which allows the user 
to activate call back. 


CAR 

Call Request 
CC 

central control 
CCS7 


Common Channel Signaling No. 7 


central control (CC) 
A part of the NT40 processor that consists of the data processing functions 
with the associated data store (DS) and program store (PS). 


Cl 

command interpreter 
CLASS 

Custom Local Area Signaling Services 
CNB 

Calling Number Blocking 
CNDB 

Calling Number Delivery Blocking 
COD 


Cutoff On Disconnect 


command interpreter (Cl) 
A component in the Support Operating System (SOS) that functions as the 
main interface between machine and user. Its principal roles include the 
following: 


e reading lines entered by a terminal user 
e breaking each line into recognizable units 


e analyzing the units 
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e recognizing command-—item numbers on the input lines 


e activating these commands 


Common Channel Signaling No. 7 (CCS7) 
A digital message—based network signaling standard defined by the CCITT 
that separates call signaling information from voice channels so that 
interoffice signaling is exchanged over a separate signaling link. 


CRA 

Call Request Activate 
CRDA 

Call Request Delete All 
CRDS 

Call Request Delete Specific 
CRR 


Call Request Retrieval 


cutoff on disconnect (COD) 
A line option that allows a line cutoff by overriding originating software call 
setup commands on disconnect by the receiving party. 


Custom Local Area Signaling Services (CLASS) 
A set of call services that provides the ability to supply calling line 
identification to the call destination, store information on the last incoming 
and last outgoing call, and monitor the status of a destination line. 


datafill 
The entry of data into tables. 


datalink 
A full—duplex data set used to connect message desk terminal devices to the 
DMS-—100 switch. It is also used to transmit messages between the message 
desk and the DMS—100 switch. 


destination point code (DPC) 
A Common Channel Signaling no. 7 (CCS7) term defining the termination 
of a signaling message. 


Digital Multiplex System (DMS) 
A central office (CO) switching system in which all external signals are 
converted to digital data and stored in assigned time slots. Switching is 
performed by reassigning the original time slots. 
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directory number (DN) 
The full complement of digits required to designate a subscriber's station 
within one numbering plan area (NPA)—usually a three-digit central office 
(CO) code followed by a four—digit station number. 


directory number suppression (DNSUPPR) feature 
The directory number suppression feature prevents directory numbers of 
restricted calling stations from being presented to a SMDI subscriber or 
message desk, or message desk agent. 


DMS 
Digital Multiplex System 

DMS-100 
A member of a family of digital multiplexed switching systems. The 
DMS-100 is a local switch. 

DN 


directory number 


DNROUTE (table) 
Directory Number Route table 


DNSUPPR 


directory number suppression 


downstream processor (DSP) 
A stand—alone computer that receives Automatic Call Distribution (ACD), 
call—-related, and agent position—related event messages generated by a 
DMS-—100 Centrex switch. The DSP stores and processes the information to 
generate real-time operation displays and historical reports. 


DPC 

destination point code 
DSP 

downstream processor 
EBS 

electronic business set 
EIA 


Electronic Industries Association 


electronic business set (EBS) 
A telephone set that provides subscribers with push—button access to various 
business features. Also known as electronic telephone set. 
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Electronic Industries Association (EIA) 
An American organization made up of manufacturers of a wide variety of 
electronic products including telecommunications equipment. The EIA is 
active in setting industry standards. 


Electronic Switched Network (ESN) 
A business communications network consisting of a number of nodes that 
are connected through dedicated links. These nodes can be all DMS—100 
Class 5 switches with Meridian Digital Centrex (MDC) software or any 
combination of DMS—100 MDC, SL—100, and SL—1 switches. These nodes 
have access to the public network. The various interconnections available to 
the network offer many possible choices for completing calls dialed by the 
network users. 


ESN 


Electronic Switched Network 


global title (GT) 
An application address that does not explicitly contain the necessary 
information that would allow routing by the signaling connection control 
part (SCCP) of the message transfer part (MTP). The SCCP global title 
translation (GTT) function is required to translate a GT into a valid network 
address. 


global title translation (GTT) 
The process that translates an application—specific address (such as a dialed 
800 number) into the Common Channel Signaling 7 (CCS7) network 
address, usually that of the appropriate service control point (SCP). 


GT 

global title 
GTT 

global title translation 
IBN 

Integrated Business Network. Preferred term is Meridian Digital Centrex. 
IBNFEAT (table) 

IBN Line Feature table 
IBNLINES (table) 

IBN Line table 
IBNXLA (table) 


IBN Translations table 
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input message 
Message formatted by the datalink interface from the message desk to be 
interpreted and sent to the appropriate station. 


Integrated Services Digital Network (ISDN) 
A set of standards proposed by the CCITT to establish compatibility 
between the telephone network and various data terminals and devices. 
ISDN is a fully digital network in general evolving from a telephone 
integrated digital network. It provides end—to—end connectivity to support a 
wide range of services, including circuit-switched voice, circuit-switched 
data, and packet-switched data over the same local facility. 


Integrated Services Digital Network user part (ISUP) 
A Common Channel Signaling No. 7 (CCS7) message—based signaling 
protocol that acts as a transport carrier for Integrated Services Digital 
Network (ISDN) services. The ISUP provides the functionality within a 
CCS7 network for voice and data services. 


input/output (I/O) 
A device or medium used to achieve a bidirectional exchange of data. Data 
exchange in the DMS—100switch is performed in accordance with the 
Input/Output Message System (IMS). 


input/output controller (IOC) 
An equipment shelf that provides an interface between up to 36 I/O devices 
and the central message controller (CMC). The IOC contains a peripheral 
processor (PP) that independently performs local tasks, thus relieving the 
load on the CPU. 


Integrated Business Network (IBN) 
See Meridian Digital Centrex. 


I/O 
input/output 
IOC 
input/output controller 
ISDN 
Integrated Services Digital Network 
ISUP 
Integrated Services Digital Network user part 
LEN 


line equipment number 
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line equipment number (LEN) 


MADN 


A seven—digit functional reference that identifies line circuits (LC). The 
LEN provides physical location information on equipment such as site, 
frame number, unit number, line subgroup (shelf), and circuit pack. 


multiple appearance directory number 


maintenance and administration position 


See MAP. 


man-machine interface (MMI) 


MAP 


MDC 


See user interface. 


Maintenance and administration position. A group of components that 
provides a user interface between operating company personnel and the 
DMS-100 Family switches. The interface consists of a visual display unit 
(VDU) and keyboard, a voice communications module, test facilities, and 
special furniture. 


Meridian Digital Centrex 


Meridian Digital Centrex (MDC) 


message (MSG) 


message desk 


A special DMS business services package that uses the data—handling 
capabilities of DMS—100 Family offices to provide a centralized telephone 
exchange service. Formerly known as Integrated Business Network (IBN). 


The unit of information transfer between nodes in the DMS—100 switch. A 
message is incoming if it is sent from a peripheral to the central control (CC) 
and outgoing if it is sent from the CC to a peripheral. A message is a type of 
control mechanism used in the I/O messages of the DMS—100 Family 
switches. The MSG byte specifies that the information to come is a data 
message. 


A combination of uniform call distribution (UCD) groups, a primary UCD 
directory number, and a full—duplex datalink. It serves as an answering 
service for stations which have their calls forwarded to the message desk. 


message desk messages 


These are messages sent by the message desk system over the datalink to 
activate or deactivate the message waiting indicator for a station. 
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Message Waiting (MWT) 
A service that allows the subscriber to receive notification of waiting 
messages. When MWT is activated, the subscriber's directory number (DN) 
is forwarded to a message desk. When a message is queued against the line, 
the MWT notification occurs. 


message waiting indicator (MWI) 
A change of state of an indicator (such as stuttered dial tone, a steadily lit or 
flashing message waiting lamp) that informs the user that a message has 
been queued against the station. 


man—machine interface. Preferred term is user interface. 


MPC 


multi—protocol controller 


multiple appearance directory number (MADN) 
A directory number (DN) that appears on more than one Meridian Digital 
Centrex (MDC) station. The stations that are assigned these numbers are 
referred to asa MADN group. MADN groups can be configured with either 
single or multiple call arrangement. 


multi—protocol controller (MPC) 
A general—purpose card that allows data communications between a 
DMS-—100 Family switch and an external computer (for example, between 
a central office (CO) billing computer and a DMS-—100 Family switch). The 
MPC card resides on the input/output controller OC) shelf. MPC card 
protocol software is downloaded from the DMS—100 CPU and then used to 
support software routines for Data Packet Network (DPN) communications. 


MWI 


message waiting indicator 


NCOS 


network class of service 


network class of service (NCOS) 
Values used to determine call privileges for calls using the network. NCOS 
values, which are encoded as part of the network signals, are transmitted as 
part of the calls between the nodes of a Meridian switched network. 


Northern Telecom (NT) 
A part of the tricorporate structure consisting of Bell-Northern Research, 
Bell Canada, and Northern Telecom. 
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NPA 


numbering plan area 


NT 


Northern Telecom 


numbering plan area (NPA) 
Any of the designated geographical divisions of the United States, Canada, 
Bermuda, Caribbean, Northwestern Mexico, and Hawaii within which no 
two telephones have the same seven—digit number. Each NPA is assigned a 
unique three-digit area code. Also known as area code. 


OM 


operational measurements 


operating company 
The owner/operator of a DMS switch. 


operational measurements (OM) 
The hardware and software resources of the DMS—100 Family switches that 
control the collection and display of measurements taken on an operating 
system. The OM subsystem organizes the measurement data and manages 
its transfer to displays and records. The OM data is used for maintenance, 
traffic, accounting, and provisioning decisions. 


output message 
Message to be formatted by the datalink interface and transmitted to the 
message desk from the DMS-—100 switch. 


PC 


point code 


PEC 


product engineering code 


peripheral side (P—side) 
The side of a node facing away from the central control (CC) and toward the 
peripheral modules (PM). 


point code (PC) 


The address of a signaling point. 


PRA 


primary rate access. Preferred term is primary rate interface (PRI). 


PRI 


primary rate interface 
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primary rate access (PRA) 
See primary rate interface. 


primary rate interface (PRI) 
An interface that carries nB+D channels over a digital DS—1 facility 
(23B+D in North America and 30B+D in Europe). PRI is used to link 
private networking facilities, such as private branch exchanges (PBX), local 
area networks (LAN), and host computers with a standardized architecture 
acting as the bridge between private switching equipment and the public 
network. Formerly known as primary rate access. 


product engineering code (PEC) 
An eight—character unique identifier for each marketable hardware item 
manufactured by Northern Telecom. 


P-side 
peripheral side 


RAG 


ring again 


ring again (RAG) 
A service that allows a calling party encountering a busy station to be 
notified when the busy station becomes idle and to be placed automatically 
in a RAG mode. 


SCCP 


signaling connection control part 


Service Order system (SERVORD) 
A user interface consisting of commands used to change, add, or delete 
subscriber lines. The format used for commands in the SERVORD comply 
with the standard telephone industry command format; for example, 3WC 
is three—way calling, ADO is add option, DEL is delete, and CWT is call 
waiting. 


SERVORD 
Service Order system 


Simplified Message Desk Interface (SMDI) 
An interface feature which enables a DMS—100 switch to communicate with 
a message desk and provides the directory number of the called station, the 
calling station number (if available), and the reason for call forwarding to a 
message desk. In addition, SMDI provides the message desk with the ability 
to activate or deactivate the message waiting indicator for any station able 
to forward calls to the desk. 
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signaling connection control part (SCCP) 
A level of Common Channel Signaling No. 7 (CCS7) layered protocol. It 
supports advanced services such as E800 and service switching point (SSP) 
and the Automatic Calling Card Service (ACCS) feature. The main 
functions of the SCCP include the transfer of signaling units with or without 
the use of a logical signaling connection and the provisioning of flexible 
global title translations (GTT) for different applications. 


SMDI 

Simplified Message Desk Interface 
SMDR 

Station Message Detail Recording 
SLLNKDEV (table) 

Link Device table 
SSN 


subsystem number 


Station Message Detail Recording (SMDR) 
In Meridian Digital Centrex (MDC), a system that provides recording 
facilities for the details of billable and nonbillable calls for each MDC 
customer group. 


subsystem number (SSN) 
The identification of a subsystem located at a Common Channel Signaling 
7 (CCS7) point code that can supply data. 


TCAP 


transaction capability application part 


TCP/IP 


transmission control protocol over internet protocol 


text messaging system (TMS) 
The text messaging system uses a visual display unit with a keyboard to 
provide the message desk agent with an information display for each 
incoming call, a text entry facility to record messages, and a text retrieval 
facility to display the messages for a subscriber. 


TMS 


text messaging system 


transaction capability application part (TCAP) 
A service that provides a common protocol for remote operations across the 
Common Channel Signaling No. 7 (CCS7) network. The protocol consists 
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UCDGRP (table) 
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of message formatting, content rules, and exchange procedures. TCAP 
provides the ability for the service switching point (SSP) to communicate 
with a service control point (SCP). TCAP is used by the ISDN layer facility 
message to transport service information for transaction signaling, not 
associated with an active call, over primary rate interface (PRI) links. 


uniform call distribution 


uniform call distribution table 


uniform call distribution (UCD) 


user 


user interface 


VFG 


A Meridian Digital Centrex (MDC) service that allows calls to be evenly 
distributed to a number of predesignated stations known as UCD stations or 
UCD positions. This service is used to queue incoming calls to the message 
desk. 


This is the person who forwards calls to the message desk UCD DN. 


The series of commands and responses used by operating company 
personnel to communicate with the DMS—100 Family switches. It is 
achieved through the MAP terminal and other input/output devices (IOD). 
Formerly known as man—machine interface. 


virtual facility group 


virtual facility group (VFG) 


VMS 


A software structure that emulates a trunk. For example, a VFG can limit the 
number of calls coming into a customer group or simulate a loop—around 
trunk without using physical trunk resources. This software also allows 
E911 data, such as serving numbering plan area (SNPA), emergency service 
number (ESN), or emergency service central office (ESCO) digits, to be 
associated with an E911 call. 


voice messaging system 


voice messaging system 


A voice messaging system is an automated recording device that 
automatically stores and plays back a caller's voice message. The message 
is transmitted exactly as it was delivered, without the intervention of a 
human agent. 
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AF3679 See SMDI Calling DN Delivery Op- 
tionality 9-47 

AF5725 See Blocking of Restricted Number to 
SMDI 9-59 


AG1638 See Message Service - Network Mes- 


sage Waiting Indicator 9-2 
AG1980 See Blocking of Restricted Number 
to SMDI 9-20 
AJ1538 See Message Waiting Indicator - PRI 
9-32 
AMAB150 log report 

description 6-7 


B 


Bringing up datalinks 

adding terminals 
datafill procedure 5-12 
datafilling table TERMDEV 5-12 
example 5-13 

datafilling table SLLNKDEV 5-14 
example 5-16 
procedure 5-15 

description 5-11 

hunt groups, adding 
datafilling table HUNTGRP 5-18 
example 5-20 
procedure, datafill 5-18 

lines, adding 5-21 
procedure, SERVORD 5-22 

returning terminals to service 
description 5-22 
procedure 5-22 

UCD groups, adding 
datafill procedure 5-17 
datafilling table UCDGRP 5-16 
example 5-18 


C 


CCS7 See Common Channel Signaling No. 7 
9-33 
Commands, SMDI 
LNKSTST 
description 4-1 
SMDICON 4-4 
SMDIDISC 4-4 
SMDILNK 4-3 
access procedure 4-2 
SMDISTAT command 
description 4-3 
Common Channel Signaling No. 7 9-33 
Connections 
Common Channel Signaling No. 7 trunks 
9-33 
primary rate interface trunks 9-33 
CS 2000 - Compact 
SOC SMDIO001 2-3 
CS 2000 - Compact, CS LAN 
connectivity illustration 1-8 
datalink redundancy 4-1 


D 

Datafilling SMDI 
error messages 2-6 
required datafill 2-3 
sequence 2-1 
Table DNROUTE 2-20 
Table IBNFEAT 2-23 
Table MPC 2-7 
Table MPCLINK 2-9 
Table SELLNKDEV 2-11 
Table UCDGRP 2-16 

Datafilling UCD groups 2-5 
recommendations 2-5 
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requirements 2-6 
restrictions 2-6 
Datafilling user stations 
requirements 2-6 
Datalink device 
NT1X89 
commands 4-1 
Datalink, SMDI 
bringing up 
adding terminals 5-12 
datafilling table SLLNKDEV 5-14 
hunt groups, adding 5-18 
lines 5-21 
procedure 5-11 
returning terminals to service 5-22 
UCD groups, adding 5-16 
bringing up See Bringing up datalinks 5-11 
datafill 3-1 
description 3-1 
failure 
description 3-2 
NT1X89 
datafill 3-1 
receiving messages 1-11 
sending messages 1-11 
states 
description 4-1 
taking down 
hunt groups, removing 5-7 
lines, deleting SMDI 5-5 
procedure 5-1 
terminals 5-3, 5-10 
tuples in table SELNKDEV, removing 5-9 
UCD groups, removing 5-6 
taking down and bringing up 
description 5-1 
printing datafill table information 5-2 
taking down See Taking down datalinks 5-3 
Device controller cards 
NT1X89 2-2 
DNSUPPR option 
blocking restricted numbers, and 9-21 
definition 1-3 
interactions 1-18 
limitations 1-18 
operation 1-14 
options 1-15 
Documentation 


Customer Data Schema, 2971001451 2-2, 

2-7, 2-9, 2-12, 2-16, 2-21, 2-23, 9-5, 9-11, 9-12, 9- 

13, 9-14, 9-15, 9-25, 9-30, 9-45, 9-46, 9-53, 9-54 

Log Report Reference Manual, 2971001840 

6-2, 6-7 

MultiProtocol Controller (MPC) Product 

Guide, 2971001015 8-1 

Nonmenu Commands Reference Manual, 

2971001820 4-2 

Office Parameters Reference Manual, 

2971001455 2-2 

Operational Measurements Reference Man- 

ual, 2971001814 8-1 

SERVORD Service Order and Query Sys- 

tem Reference Manual, 2972101808 7-1 

Station Message Detail Recording Refer- 

ence Guide, 2972071119 6-8 
DYNAMIC_MEMORY_SIZE 9-7 
Dynamic_Memory_Size. 9-8 


F 


Feature interactions 
call request delete all(CRDA) 9-7 
Calling Number Delivery Blocking 
(CNDB) option 2-2 
DNSUPPR option 2-2 
LASTFWDN option 9-24 
message service - list management (MLE) 
9-7 
message waiting indicator 9-3 
Network Automatic Call Distribution 
(NACD) 9-44 
network executive message waiting (Net- 
work EMW) 9-44 
network message service (NMS) 9-44 
Network Message Waiting Indicator (Net- 
work MWI) 9-44 
Network ring again (Network RAG) 9-44 
Feature names 
Message Waiting Indicator - PRI 9-32 
RES High Speed SMDI 9-59 
SMDI 
Called DN Option and KSH Support 9-27 
SMDI Calling DN Delivery Optionality 9- 
47 
Feature numbers 


297-2051-104 Preliminary 13.01 September 2004 


AF3679 9-47 

AF5725 9-59 

AG1638 9-2 

AG1980 9-20 

AJ1538 9-32 

NC0009 9-27 

Feature packages 

NTX732AA 9-27, 9-59 

NTX797AA 9-2, 9-32 

NTXA68AA 9-2 

NTXNO7AB_ 9-47 

NTXNIOAA 9-59 

NTXNO7AA 9-20 

FTRQ operational measurement group 

description 9-15 

key fields 
FTRQ32WAREAS 9-16 
FTRQ32WPERMS 9-16 

registers 
FTRQHI 9-16 
FTRQOVFL 9-16 
FTRQSEIZ 9-16 


l 
INTERWRK SCCP subsystem 
description 9-39 


L 


LOG report 
NMS104 9-19 

Log report 
NMS103 9-18 

Log reports 
AMAB150 6-7 
description 6-1 
NMS100 9-17 
NMS101 9-18 
NMS102 9-18 
RES High Speed SMDI 9-68 
SLNK107 6-4 
SMDI100 6-8 
SMDI101 6-8 
SMDI102 6-8 
SMDI104 6-9 
SMDI105 6-9 
SMDI106 6-10 
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Message desk 


communication 
datalink 1-11 
voice lines 1-10 
definition 1-3 
multiple connections 1-11 
systems See Text messaging system 1-3 
systems See Voice messaging system 1-3 


Message retrieval 


text messaging system 1-5 
voice messaging system 1-9 


Message Service - Network Message Waiting 
Indicator 


activation, message waiting indicator 
SMDI system 9-5 
voice messaging system 9-4 
background information 9-3 
datafill sequence 9-11 
datafilling table C7GTT 
description 9-13 
example 9-13 
procedure 9-13 
datafilling table C7GTTYPE 
description 9-12 
example 9-12 
procedure 9-12 
datafilling table C7LOCSSN 
description 9-14 
example 9-14 
procedure 9-14 
datafilling table CINETSSN 
description 9-11 
example 9-12 
procedure 9-11 
datafilling table C7RPLSSN 
description 9-14 
example 9-15 
procedure 9-14 
datafilling table C7RSSCRN 
description 9-15 
example 9-15 
procedure 9-15 
deactivation, SMDI system 9-5 
deactivation, voice messaging system 9-5 
description 9-3 
feature interactions 
call request delete all(CRDA) 9-7 
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message service - list management (MLE) 9- 
7 
feature package prerequisites 
NTX797AA 9-3 
NTXA68AA_ 9-2 
limitations and restrictions 9-6 
log reports 
description 9-17 
message waiting 
description 9-3 
office parameters 
datafill procedure 9-8, 9-9 
example 9-8, 9-11 
operation 9-4 
operational measurements 
FTRQ group 9-15 
NETMSG group 9-16 
SMDI system 
retrieval procedure 9-6 
transaction capability application part 
(TCAP) messages 
description 9-4 
error messages 9-6 
voice messaging system 
retrieval procedure 9-6 
Message waiting 
capabilities 1-11 
Message Waiting Indicator - PRI 
activation and deactivation procedures 9-43 
background information 9-33 
datafill sequence 9-44 
datafilling table MSGRTE 
description 9-45 
datafilling table NETNAMES 
description 9-44 
example 9-45 
procedure 9-45 
deactivation 9-33 
description 9-33 
example 
datafill for 9-42 
description 9-41 
feature interactions 


Network Automatic Call Distribution 
(NACD) 9-44 
network executive message waiting 


(Network EMW) 9-44 
network message service (NMS) 9-44 


Network Message Waiting indicator 
(Network MWI) 9-44 
Network ring again (Network RAG) 9-44 
feature package prerequisites 9-32 
INTERWRK SCCP subsystem 
description 9-39 
limitations and restrictions 9-43 
operation 9-34 
primary rate interface (PRI) facility process 
description 9-38 
SCCP NMS subsystem 
description 9-40 
Table MSGRTE 
description 9-35 
example 9-36 
route selectors 9-36 
LOCAL 9-36 
PRA 9-36 
SS7 9-36 
Table NETNAMES 
MWRBYTE option 9-37 
NMSTBRTE option 9-34 
transaction capability application part 
(TCAP) messages 
description 9-34 
incoming messages 9-38 
Messages 
incoming 3-2 
example 3-2 
outgoing 3-3 
call detail 3-3 
example 3-3 
message waiting indicator change failure 3-3 
protocol 3-2 


N 


NC0009 See SMDI 
Called DN Option and KSH Support 9-27 
NETMSG operational measurement group 
description 9-16 
registers 
NMSDENL 9-16 
NMSINVAD 9-17 
NMSTIME 9-16 
NMSVACT 9-17 
NMS 100 log report 
description 9-17 
example 9-17 
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NMS101 log report 

description 9-18 

example 9-18 
NMS 102 log report 

description 9-18 

example 9-18 
NMS 103 log report 

description 9-18 

example 9-19 
NMS 104 log report 

description 9-19 

example 9-19 
NMS_ACKNOWLEDGEMENT_TIMEOUT 
9-7 
NO_OF_SMALL_EXT_BLKS 9-7 
NO_OF_XLARGE_EXT_BLKS 9-7 
NT1X67 datalinks 

office parameters 2-2 
NT1X89 datalinks 

commands 4-1 

datafill 3-1 

office parameters 2-2 
NTIX89AA card 

description 2-2 
NTIX89AA card See NT1X89 datalinks 2-2 
NTX732AA See SMDI 

Called DN Option and KSH Support 9-27 
NTX732AA See SMDI Data Link Reengi- 
neering 9-59 
NTX797AA See Message Service - Network 
Message Waiting Indicator 9-2 
NTX797AA See Message Waiting Indicator - 
PRI 9-32 
NTXA68AA See Message Service - Network 
Message Waiting Indicator 9-2 
NTXNO7AA See Blocking of Restricted Num- 
ber to SMDI 9-20 
NTXNO7AB See SMDI Calling DN Delivery 
Optionality 9-47 
NTXNIOAA See SMDI Data Link Reengi- 
neering 9-59 


O 


Office parameters 2-2 
AUXCP_CPU_SHARE 2-2 
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GUARANTEED_TERMINAL_CPU_SHA 

RE 2-2 

KSHUNT_EXT_BLOCKS 9-29 
OM See Operational measurements 8-1 
Operational measurements 

description 8-1 

FTRQ group 9-15 

NETMSG group 9-16 

SLLNK group 8-1 

SLLNKINC group 8-1 


P 


PRI See Primary rate interface 9-33 

Primary rate interface 9-33 

Primary rate interface (PRI) facility process 
description 9-38 


R 
RES High Speed SMDI 
background information 9-60 
datafill sequence 9-67 
datafilling table SLLNKDEV 
description 9-67 
example 9-68 
procedure 9-67 
description 9-59 
feature package prerequisites 9-59 
limitations and restrictions 9-66 
operation 9-60 
RES SMDI CLID Suppression 
activation and deactivation procedures 9-24 
background information 9-20 
blocking directory numbers 
description 9-21 
example 9-22 
scenarios, possible 9-23 
datafill sequence 9-25 
datafilling table SLLNKDEV 
description 9-25 
example 9-25 
procedure 9-25 
description 9-20 
feature interactions 9-24 
LASTFWDN option, with 9-24 
SMDI, with 9-24 
feature package prerequisites 9-20 
limitations and restrictions 9-24 
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operation 9-21 

restricted directory number 
activation 9-21 
description 9-20 


S 
SCCP NMS subsystem 
description 9-40 
SERVORD 5-5 
ADO (add) command 7-1 
DEO (delete) command 7-2 
description 7-1 
example 5-22, 7-1 
Simplified Message Desk Interface See SMDI 
1-1 
SLLNK operational measurement group 
description 8-2 
measurements 
SLLNKOK 8-2 
SLLNKOVF 8-2 
SLLNKQU 8-2 
SLLNKINC operational measurement group 
description 8-2 
measurements 
SLLNKBAD 8-3 
SLLNKIOF 8-2 
SLLNKIOK 8-2 
SLLNKIOV 8-2 
SLLNKIQU 8-3 
SLNK107 log report 
description 6-4 
SMDI 
Called DN Option and KSH Support 
activation and deactivation procedures 9-28 
background information 9-28 
Called DN option 
description 9-27 
operation 9-28 
datafill sequence 9-30 
datafilling table SLLNKDEV 
description 9-30 
example 9-30 
procedure 9-30 
description 9-27 
feature package prerequisites 9-27 
key short hunt (KSH) 
description 9-27 
operation 9-28 


limitations and restrictions 9-28 
office parameters 9-29 
operation 9-28 
compatibility 1-1 
feature interactions 
features 
Message Waiting Indicator - PRI, AJ1538 9- 
32 
Message Waiting Indicator - PRI, AJ1538 
See Message Waiting Indicator - PRI 
9-32 
RES High Speed SMDI, AF5725 9-59 
SMDI 
Called DN Option and KSH Support 9-27 
Called DN Option and KSH Support See 
SMDI 
Called DN Option and KSH 
Support 9-27 
SMDI Calling DN Delivery Optionality 9-47 
SMDI Calling DN Delivery Optionality See 
SMDI Calling DN Delivery 
Optionality 9-47 


1-13 


functions 
call forwarding 1-1 
message waiting 1-1 
uniform call distribution 1-1 
message waiting 
capabilities 1-11 
restarts 1-14 
sample message 1-9 
SMDI Calling DN Delivery Optionality 
activation and deactivation procedures 9-52 
background information 9-48 
datafill sequence 9-53 
datafilling table HUNTGRP 
description 9-54 
example 9-55 
datafilling table UCDGRP 
description 9-53 
example 9-54 
description 9-47 
feature interactions 9-52 
feature package prerequisites 9-47 
limitations and restrictions 9-52 
operation 9-49 


SMDI100 log report 


description 6-8 


SMDI101 log report 


description 6-8 
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SMDI102 log report 
description 6-8 
SMDI104 log report 
description 6-9 
SMDI105 log report 
description 6-9 
SMDI106 log report 

description 6-10 
SOC 


Index B-7 


Table IBNFEAT 5-5, 5-21 
description 2-23 
example, datafill 2-24 
procedure, datafill 2-23 

Table IBNLINES 
SERVORD example 7-1 

Table MPC 2-3 
description 2-7 
procedure, datafill 2-7 


SMDIO0001 for CS 2000 - Compact 2-3 Table MPCLINK 2-3 


T 
Table C7GTT 
description 9-13 
example, datafill 9-13 
procedure, datafill 9-13 
Table C7GTTY PE 
description 9-12 
example, datafill 9-12 
procedure, datafill 9-12 
Table C7LOCSSN 
description 9-14 
example, datafill 9-14 
procedure, datafill 9-14 
Table C7NETSSN 
description 9-11 
example, datafill 9-12 
procedure, datafill 9-11 
Table C7RPLSSN 
description 9-14 
example, datafill 9-15 
procedure, datafill 9-14 
Table C7RSSCRN 
description 9-15 
example, datafill 9-15 
procedure, datafill 9-15 
Table DNATTRS 2-2 
Table DNGRPS 2-2 
Table DNROUTE 
description 2-20 
example, datafill 2-22 
procedure, datafill 2-21 
Table HUNTGRP 
description 9-54 
example, datafill 5-20 


procedure, datafill 5-18, 9-54 


description 2-9 
example, datafill 2-10 
procedure, datafill 2-9 
Table MSGRTE 
description 9-35 
example 9-36 
route selectors 
LOCAL 9-36 
PRA 9-36 
SS7 9-36 
Table NETNAMES 2-2 
description 9-44 
example, datafill 9-45 
MWRIBYTE option 9-37 
NMSTBRTE option 9-34 
procedure, datafill 9-45 
Table OFCENG 2-2, 9-7, 9-29 
datafill procedure 9-8, 9-9 
example 9-8, 9-11 
Table OFCENG See Office parameters 2-2 
Table SELNKDEV 2-2 
adding tuples 5-15 
description 2-11, 9-25, 9-30, 9-67 
example, datafill 2-15, 5-16, 9-25, 9-30, 9-55, 
9-68 
procedure, datafill 2-12, 5-14, 9-25, 9-30, 9-67 
removing tuples 5-9 
Table TERMDEV 5-3, 5-10 
adding terminals 
datafill procedure 5-12 
example, datafill 5-13 
Table UCDGRP 
adding UCD groups 
datafill procedure 5-16 
description 2-16, 9-53 
example, datafill 2-19, 9-54 
procedure, datafill 2-16, 9-53 
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Taking down datalinks message retrieval 1-9 

description 5-1 network activation 

hunt groups, removing message waiting indicator 9-4 
description 5-7 network deactivation 
example 5-8 message waiting indicator 9-5 
procedure 5-7 operation 1-6 

lines, deleting SMDI 
description 5-5 W 


example 5-6, 5-21 
procedure 5-5, 5-21 
terminals, deleting 
description 5-10 
example 5-11 
procedure 5-10 
terminals, taking offline 
description 5-3 
procedure 5-4 
tuples in table SLLNKDEYV, removing 
description 5-9 
example 5-10 
procedure 5-10 
UCD groups, removing 
description 5-6 
example 5-7 
procedure 5-6 
TCAP See Transaction capability application 
part messages 9-4 
Text messaging system 
call answering 1-10 
message retrieval 1-5 
operation 1-3 
Three-way Calling 9-29 
TMS See Text messaging system 1-3 
Transaction capability application part mes- 
sages 
description 9-4, 9-34 
error messages 9-6 
global title translations (GTT) 9-33 
incoming messages 9-38 


V 


VMS See Voice messaging system 1-3 
Voice lines 
connection 
activation 1-10 
deactivation 1-10 
Voice messaging system 
call answering 1-10 


With the LASTFWDN option 9-29 
Without the SMDI 
9-29 
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